Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

5
  • 1
    I tend to not be a fan of code generation based on DB because this means building your system is explicitly dependent on correct deployment of the system existing, which can cause build errors and being that they're in automatically generated code, they're unlikely to be found before runtime. Sometimes it is the right solution I agree, but I think that's more rare than otherwise. Commented Jan 28, 2013 at 22:45
  • 1
    @JimmyHoffa - If you end up with the same thing in the end, which place you designate as the source is a matter of convenience. But if you base it on the DB then you generally will put the data in the DB via some (source controlled) script. So usually filling the DB from your code is more convenient if a programmer is doing it. Commented Jan 29, 2013 at 1:07
  • Ah, I was referring to code generation from the database, going the other way and actually filling the database from the code is something I'm fine with; it relies on run-time realities that way rather than build-time prayers :) Commented Jan 29, 2013 at 2:25
  • Currently I'm using T4 to generate the enums. I don't think adding fields to a dropdown ( what most of our lookup tables do) warrants a recompile and redepoly. That just seems silly. Commented Jan 29, 2013 at 14:00
  • 1
    @nportelli - As I said, it really only makes sense if the enums only change between releases. Commented Jan 29, 2013 at 17:58