26 July 2006
On Competing Application Models
Within MVCs, the model (data layer) perhaps gives the most trouble while conceptualizing. At a basic level, it’s acutally OK: A model is just a place to store data. But as a developer adds more patterns and buzzwords to the application, it becomes harrier. Is a model just the conveient way to access database records? Does the database code belong in the model or in the controller? Models aren’t quite so easy once they’re actually being used.
Considering different languages, platforms and frameworks, there are actually three different models representing the same data: A domain model, database record model(s) and an output model. Not all environements use each model– ASP.net encourages using the output model as a domain model, as well. And through data binding and abstraction, there isn’t really a special model for records at all: They’re just implementations of DataSet’s, DataRow’s and DataTable’s. So an abstract DataSet gets bound to a form (.net’s domain model) and you’re left with just one.
Unfortuently, it can be a big jump to a form model from an abstract record. And some things just don’t transfer cleanly at all: ASP.net forms get messy when dealing with any domain model converying more than One True Idea. Another big deal right now is Ruby on Rails. In Rails, there is only one model. You must write code to fetch a record as a model, but the model gets scaffold-ed into usable applications by magic. This has a number of advantages over ASP.net’s style; the biggest being that there’s only one model. It also has disadvantages, the biggest being that in having just one model, the programmer must thing relationly. That is less that conduive to productivity to me. Admitally, ASP.net also has this requirement, but by featuring a data model AND a domain model, it encourages use of a DBA for that part of things. Rails also discourages reuse because, through scaffolding, an optimized model was never created and so the model must be massaged wherver it will be used.
Perhaps unfortuently, while I have focused on the problems of these two frameworks, they are the best real world implementations of Models that I’ve seen. ORM products address these problems but only at the expense of more overhead code. Fortitude (and specifically, Fortitude Object Data Adapter) prevents these.
| Data Model | Domain Model | Output Model | |
| Rails | Yes | No | No |
| ASP.net | Yes | No | Yes |
| Fortitude | No | Yes | Yes |
Fortitude Object Data Adapter is effectively a transparent ORM. It frees application developers from doing any database modeling. Like .net, it is easy enough for a DBA to come in later and address the physical database layer, but it offers a free working solution. The Domain Model is where Fortitude concentrates its focus. The Domain Model is really the purest of the three: It is not constricted by the limitations of controls or the datatypes a database provides. It’s not Human idea pure, but it allows aggreagation without the consequences of having to generate the relations. Finally, the output layer (Fortitude Forms) is really an Output Model. It’s purely a transititve structure, though, as a Form Model gets transformed back into a Domain Model. But for convience during development, there is a Form Model.
It is unfortunante that practice really neccessitates a second model. Rails only skirts around it by generating the code. But many applications written in the first half of this decade are tragically forced to take on another Model yet, as most web frameworks are light on the View side. Many developers have turned to Smarty. But while Smarty does have many time saving benefits, its not as elegant or easy-to-conceptualize as ASP.net, and perhaps worst of all, requires duplication of the entire Domain Model with no automatic facility to accellerate it. Smarty helps to scale, not to develop.
There are just too many practical limitations to keep only one model. An Output model, even if its nothing more than to buffer user’s input during validation, is a very valuable device. And if you require two models, keeping things integrated is helpful. Either Rails or ASP.net get you 2/3rds of the way there. Only Fortitude will deliver all three layers for you, as automatically as is reasonably possible.