2 ms·

I recently wrote one for C# / MSSQL. I've been using EF on side projects, but work was concerned with it, so I just wrote a CRUD sproc / Entity / Repository / S

I recently wrote one for C# / MSSQL. I've been using EF on side projects, but work was concerned with it, so I just wrote a CRUD sproc / Entity / Repository / Service / DTO generator. Connect to a database and select the tables you want to build for, and done. 5 layers of abstraction in under a second. It gets me to about 95% of what I need and I custom build the special circumstance stuff from the generated objects. It creates the "if exists / drop" stuff, exception handling and comments w/ dates in the sprocs that reference the objects in C#, and vice versa, what table was referenced, proper [Key] and [MaxLength] attributes, etc. Puts them in their proper folders for git too. It does exactly what I would have done had I done it manually. Works great with no ORM abstraction and it was fun to write.

unclebucknasty 8y ago
Yeah, very similar--with one primary enhancement: That is, I initially started generating objects-per-table, but found that it was a little limiting for a lot of use-cases I encountered. In particular, it didn't cover joins very well--particularly for queries that fed list views. So, I expanded into supporting raw SQL SELECT queries that can include joins, which I parse and combine with DB metadata. I then generate the DTOs from there. So, a single DTO can have properties mapped to different tables, which I found much less redundant/limiting than entity-per-table designs. In addition to the SELECT code, I can use simple checkboxes to also generate INSERT/DELETE/UPDATE/UPSERT code, which map the DTOs back to the underlying tables. It recognizes keys and includes multiple-table writes in a single transaction, etc. In addition to the DTOs and the DAO layer, it can also optionally generate a service interface. Of the utilities I've written over the years, it is the one that most stands out as having paid me back incalculably.

unclebucknasty 8y ago

Yeah, very similar--with one primary enhancement: That is, I initially started generating objects-per-table, but found that it was a little limiting for a lot of use-cases I encountered. In particular, it didn't cover joins very well--particularly for queries that fed list views. So, I expanded into supporting raw SQL SELECT queries that can include joins, which I parse and combine with DB metadata. I then generate the DTOs from there. So, a single DTO can have properties mapped to different tables, which I found much less redundant/limiting than entity-per-table designs. In addition to the SELECT code, I can use simple checkboxes to also generate INSERT/DELETE/UPDATE/UPSERT code, which map the DTOs back to the underlying tables. It recognizes keys and includes multiple-table writes in a single transaction, etc. In addition to the DTOs and the DAO layer, it can also optionally generate a service interface. Of the utilities I've written over the years, it is the one that most stands out as having paid me back incalculably.