Coffeehouse Thread

17 posts

Have you ever used code generation?

Back to Forum: Coffeehouse
  • Bas

    I've been messing around with Model First entity framework stuff and needed to generate a SQLite database from it, and as such I learned about the T4 engine in Visual Studio. After reading up on it a bit I was thinking of what T4 templates I could write, and drew a blank. Apart from the obvious built in stuff like XAML to C# or EDMX to SQL or C#, I don't think I've ever had a need to generate code.

    Have any of you ever used it, and if so, what for? I'm wondering if there's some obvious way to do less work be more productive that I'm just not seeing.

  • Dr Herbie

    @Bas: I have a small number of T4 templates to generate property-compatible DTOs from ADO.NET datasets (so we can migrate data to web services, etc) -- the template ensure that when fields are added or removed from the datasets, the DTOs match.

    In my previous job I had code generation scripts that read database schema and created our own custom DTOs and services (this was .NET1.1 and no one had heard of generic object mappers).

    Herbie

  • itsnotabug

    PetaPoco has some T4 templates that allow you to auto-generate the POCO classes against an existing database. It's a great time saver.

    edit* now that i think about it, a cool T4 project would be to automatically generate POCO deserialization classes from actual JSON. That could make working with restful JSON services a little easier.

  • ScanIAm

    yep, the only place I've seen code generation used in the wild was for DTO creation.

  • Ion Todirel

    yes, I use C macros to generate code

  • DaveWill2

    Where have these been.

    Before Visual Studio .NET I recall writing many a utility whose sole purpose was to write code for me.  Usually some boiler plate or repetitive code that had some domain specific something that made it unique.  We did a lot of custom code then.

    Generating POCOs via T4 templates sounds a lot more fun than via T-SQL.

  • Harlequin

    Our CTO 6 years ago built a simple UI app, where you plug in classes and properties, and it generated all the C#, all the SQL stuff, all the BL, all the CRUD. Was pretty neat tool and saved a lot of time.

  • Deactivated User

    Comment removed at user's request.

  • itsnotabug

    yeah, "pseudo" development platforms could make use of code generation. imagine a runtime engine with a separate designer that allows you to visually create new runtime objects, set properties, wire up relationships, ect, then the code generator implements any number of core engine interfaces and dumps out the runtime models... although i'm not sure if T4 templates can be used outside of VS. 

  • Bas

    @itsnotabug: AFAIK it's available as a command line tool. I doubt you'd be allowed to distribute it or anything though.

  • Ian2

    I had a copy of an Application Genrator for dBase that was quite useful in its' day.  Damned if I can remember what it was called. 

    Think it might be out in the garage somewhere ...

  • mstefanik

    Unless you're writing in assembly (or arguably, machine code directly with a hex editor), then you're using a code generator. So the most correct answer would be, "yes, the vast majority of us do".

  • FuncOfT

    Sure, I've used LLBLGen and many others including T4 templates, over the years.  Here's an example of how we use some T4 templates here:  http://cscodegen.codeplex.com/ 

  • vesuvius

    I use Resharper daily and GhostDoc as well. I think you have to put a heck of a lot of time into developing a specific bit of functionality that generates code, so for small teams, it is impractical to create a tool,  unless there is a domain specific function that is not freely or commercially available.

    T4 templates are highly regarded, especially as a replacement for CodeDom that Microsoft have used in a lot of their design tools, and would definitely be the one technology I would look at if I was going to look at creating something.

  • Michael Butler

    Over the years, I've used a lot of code generation. Whether it be self-built tools or things like T4 or other third party products. I used to use CodeDom but that was sometimes more work than I wanted to do.

    I use it because I'm the kind of programmer who doesn't enjoy doing all the typing. So if I have large table which needs to have data stored in it, i'll create the table and then auto generated the SQL Upsert script, the C# SQL access code and the POC.

    I find that lots of code I write usually follows some kind of pattern, and if it uses a pattern then you can usually figure out a way for the code to be generated for you.

    Of course, with things like Entity Framework then I don't need to use my own tools as much as EF do a lot of the boring stuff for me.

    The code generation I use is usually a one off and I don't expect the tool to be able to cope with my manual changes. They are just "wizards" to get the boring boiler plate out of the way so I can get the app up and running and get on with the real business logic.

     

  • Bas

    As far as I can tell, people are mainly using it for database to POCO stuff. I had hoped there'd be some other use for it that I'm missing, but apparently not.

  • FuncOfT

    @Bas: We're not ... it's way above the DB layer.  The code wraps other, more complex boilerplate that you'd normally have to write.  In our case, we have metadata defined in XML and a programmer normally would have to write a bunch of code to tie into the metadata, so we use T4 templates to build up that code for them. 

    In any scenario where code generation makes sense, however, you'll find the same principals in action - wrap more complex processes and/or objects into simpler processes and/or objects.  However, at some point you wonder, isn't there a better design that eliminates all this repetitive boilerplate code?  Yes, there probably is.  In the meantime, while we discover that, code generation can be an excellent stop-gap measure to take.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.