The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Amazing as I have been doing just that for 30+ years, by the great Ghu I must rethink my entire development strategy as I generate the API code, the client DAL, the controllers and some of the UI controls based on the database structure.
Never underestimate the power of human stupidity -
I'm old. I know stuff - JSOP
I recently generated a service based on a WSDL (which is XML).
I had to do the implementation myself and heavily tweaked the generated code and it was WCF which I generally hate so it was all personal hell, but I'm using generated code now.
I generate the database using EF Code First (so that's not XML).
I've generated UI's from the DB in the past, which never really works out the way you want to.
Generally, I dislike working with XML, so mostly 4 and 5.
Think about a set of stored procs in a database that I want an application to be able to call. I have three alternatives:
1. I can write a common CallProc method, that calls any proc with an array of arguments
2. I can generate a single method for each one using the database metadata including typed arguments.
3. I can hand write number 2.
Clearly, option 3 is inefficient, from a developers time, the riskiest for defects.
Option 2 is the most extensible - no additional work is required to add a new proc to the system.
Option 1 presents the programmer calling procs with the nicest API. It is also likely to be the most performant (any performance tweaks coded in the others can be included in the generation templates)
Option 1 will be the largest code footprint, and an extra code generation step is required to generate the code, so ease of use depends on the level of support for this in the development environment
Hence I vote for 1.
It's almost a clarification to the DRY principle - Don't repeat yourself, have a code generator repeat yourself.
However for generation to be viable, the generated code must never be edited. This is why partial classes in c# and similar are almost essential.
The second part of the question, is if generation is to be used, what should the model be: DB source or code or external model.
Here we stumble into the classic 'impedance mismatch', The ideal database model does not correlate with the ideal code class structure. This mismatch is why people will hate code generation. Too many ORMs are simply mapping 1 table to 1 class. When generated from the code, the database structure is often sub-optimal and likewise the other way around.
There are parts of a code model difficult to express in a database model.
What you end up with is essentially an independent development environment, so it can be taken too far.
I haven't done much with generating UI code yet - the partial class constraint tends to keep me from exploring this in detail..
I tend to generate stuff out of the C# domain model - using code attributes to control the generation (including the "don't even try to generate this, I'll write it myself" settings of course). Originally I did it with reflection on the compiled domain model, but the last time I used Roslyn - which was kind of OK. Though I had to generate more than the DAL/UI (converters for a versioned API, gRPC layers to transition between processes and other enterpricy stuff).
1. generate DAL, admin UI and DB from an XML schema source?
That one, except at this point I'd probably use JSON. The problem is, whatever the schema is in, there needs to be a good way to detect changes and migrate those changes to the DB.
#1 has the advantage that additional metadata can be put into it that isn't necessarily captured by the pure DB schema. The problem though is that it can quickly start to look like a UI view definition, which can vary while the schema stays constant. So that trap needs to be avoided, though I don't see any reason why the schema metadata can't define certain defaults, like the default control type to render on the UI.
Also, the DAL is often overkill -- most of the time, you don't need a DAL to serialize the records into class instances, only to map the class properties to UI elements (whether WinForm or web UI's). There's so much automation that can be done (and that I have done) to eliminate the "class" middleman and determine the DB transaction from the table changes directly.