Building the Application off the Database

</p>

A couple things are bothering me this morning. I had a potential client asking me about IdeaBlade from DevForce as a possible application framework. I looked at their developer’s guide for about 15 minutes and it was enough for me to go thumbs emphatically down.

Specifically, I wouldn’t want to touch it because it:

• Creates the “Domain Model” directly from the database with a designer tool. I’ve always detested this model. I think it forces or at least tempts you into BDUF. Incremental changes are clumsy when you have to fire up the designer GUI instead of just making a code change. It’s easier to do evolutionary design with POCO’s than it is to constantly morph the database and regenerate. Lastly, for anything remotely complex I almost always find a reason to make the Domain Model structure deviate from the physical database structure. Locking the two things together almost always lead to one model or the other sucking.

There can really only be 1 true model. It either exists in the database or in the application. If you generate off the data model, it is the one true model. I have yet to see an implementation that will roundtrip between the two–ie..generate off the data model but then update the data model off app changes. Without roundtrips, it just reinforces the “one true model” stigma.

You can see the same problem with code generation. If the code generation doesn’t support roundtripping, the templates basically have to become the “one true source” that you work with and around (partial classes, etc). They become the central driving concept in development.

My personal opinion is that you are better off realizing what the one true model is and not fighting the current. That’s also why I really don’t enjoy generating the app off the database. I much prefer making POCOs the one true model.

In the “one true model”, you do have to make compromises so that you don’t trash the other model all to hell, but that’s about the best I’ve found you can do. After you learn one modelling paradigm (or both) really well, the incompatibilities really start to show.

In short, I agree with you–although it’s not an argument of BDUF to me. It’s an argument of how I choose to work and where I find the most power lies (for tackling complexity with the least amount of effort and greatest robustness/agility to change).

This argument also has built in assumptions though. I’m assuming there is complexity or a high rate of change. If an app invalidates those assumptions, my argument has no wind (and I would reevaluate my tooling). For example, without complexity (Forms over data), the two models can basically be mirror images.

I want to say that this type of “spit out an application” to match the database is only useful for simple CRUD apps, and not very many systems really fit that description.

Agreed, unless the developer is more DBA than programmer. 😉

• It’s an ActiveRecord approach and that still bugs me to have data access stuff jumbled up in my Domain Model. I know that argument never dies, but is it really that hard to use NHibernate like ORM’s with a Unit of Work?

No. It’s not. (Oops. Was that rhetorical?)

• Mobile Objects: I bump into this from time to time. The idea that systems are easier to build if the same set of domain objects can run on both client and server. It saves duplication on validation and that’s cool, but the idea of running the same domain model on both client and server smacks of very tight coupling to me. This DevForce thing, Astoria, CSLA.Net and whatnot just smell wrong. I say that the domain model should follow from behavior, not data structure, and the behavior could easily be different from client to server side. When I’ve seen CSLA stuff running on the server side the code looks way too busy because of all the extra StartEdit() blah, blah stuff that’s there for running on the client side.

I’ll defer to Fowler on this one. To quote him:

Fowler’s First Law of Distributed Object Design:
Don’t distribute your objects!

Or to pull a more choice quote, “this design sucks like an inverted hurricane”.
http://www.ddj.com/architect/184414966

I’m not a big SOA fan, but having some loose coupling between a desktop client and the backing services is just plain good fundamental design.

Screw SOA. It’s just good design.

What do you guys think? Am I being too harsh, or not being open minded? I really don’t want anything to do with this kind of solution but you never know…

You don’t have to give yourself a lobotomy to be open-minded.

Why are they picking this tool in the first place? Does it give them a strategic advantage over their competitors? If there’s no business reason, they should be having a conversation with you (the expert) on what you know works (and what you know can be effective when building the app). If that’s the case, tell them to put the shiny thing back in the store window where it belongs.