Geeks With Blogs

News Google

Nick Harrison Blog<Nick>.Next()

As we have pieced together the components of a web application we have explored how best to structure the markup, and how to pull business logic out of the UI by following the Model View Presenter Pattern. Now let's turn our attention to the Model as we pull all the pieces together and explore what a well behaved model might look like. 

The Model will be the piece that handles storing and retrieving our data. Just as we did with the markup and view, we want to provide a separation of concerns and try to shield ourselves from the more volatile aspects of our design.


Model, Model, Everywhere

Software development is full of models. We have domain models, physical data models, logical models, process models, etc. Sometimes the terminology can be confusing and the differences subtle and often abused. Let's try to clear some up some of the confusion.

A domain model is an informal way of thinking about data and how the data components relate to each other independent of any technology or formal structure. We think about relations but not constraints. We think about associations but not inheritance, and we think very loosely about data types, if at all. The domain model is the ultimate in fluid informal discussion.

A physical data model is the implementation of a domain model in a specific database. While the domain model is independent of any technology, the physical data model is very dependent on a particular database platform. It may even be dependent on a particular version of the selected database. In some cases, it may even be dependent on a particular disk configuration with a specific operating system.

The domain model is free from any technical constraints leaving many implementation details to be resolved in the physical data model. For example, entity names in the domain model can be anything, while entity names in the physical data model are limited to what the RDMS can handle. The domain does not have to worry about performance or maintenance. Most of the details in the physical model are consumed by these concerns.

Here we will focus most of our discussion on the development model. The relationship between the domain model and the development model is similar to the relationship between the domain and physical data models - similar but not exact.

The development model is the implementation of a domain model in code.

Ultimately, the development model will be expected to store and retrieve data from the physical data model. The development model also has restrictions and extensions that the physical data model never has to deal with. The development model can benefit from inheritance and polymorphism, and encapsulation, but also has to deal with the often self-contradictory business logic.

The development model is also the last line of defense protecting the data in the database. Validations in your code protect the data better than any constraint, firewall, or the best security measures that a security administrator can put in place.

Read More ...

Posted on Sunday, June 27, 2010 8:42 AM | Back to top

Comments on this post: Back to Basics: Wiring up a Web Application

comments powered by Disqus

Copyright © Nick Harrison | Powered by: