Building the Application off the Database

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”.

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.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

4 Responses to Building the Application off the Database

  1. Robz says:

    I don’t think you are being too harsh. I don’t like tools that couple you to the database design either. The relational database model is a way to store information, but BCNF doesn’t always make for great objects, and it gives you no freedom to make changes without having to make them on the rigid data sctructure.

  2. Robz says:

    structure….spelling checker not so good.

  3. If there’s one true model, then the class model and the data model are inevitably representations of it, rather than of each other! :)

    You made an interesting point about differences in friction when the developing from POCO’s or from the data model, but I think that your estimation of coding from the data model isn’t entirely clear.

    It appeared to me that you’re saying that it’s easier to use the POCO’s because when bringing the model into play from the database, the tooling has a higher coefficient of friction than in simply spec’ing a POCO model.

    If I read you right, it seems to be a comment about the tooling rather than the nature of the impact to the process when the model comes into play through POCO’s or through the database.

    In Rails, I introduce all model changes incrementally using migrations. I can change the model a column at a time if needed.

    As long as we can propagate micro-incremental changes from either representation in a low-friction way, we’re in good shape.

    Choosing Active Record or Domain Model should be a decision that’s made because of the benefits that the patterns bring to the solution rather than the friction that either causes.

    The tools that we have in .NET to harmonize the models micro-incrementally don’t serve either Active Record or Domain Model really well yet.

    Imagine a plug-in that that generates a property from test-code that also adds mapping and modifies the database :)

  4. (Ditto what Scott said).

    The ideal is a model that automatically updates both the code and the database. It is actually not that difficult to do, and definitely worth the investment on a long-term project.