Over the last year I have been working on a couple of applications (Winforms) that use the MVP pattern. There is a lot of articles published covering MVC and MVP to various degrees of detail.  They all seem to stop at the point where you have one controller, one view and a simple model.  I am trying to find out if anyone else has been trying to solve the same problem in the same way.  Very little of the literature actually describes the implementation of a Domain Model.

The model component consists of a Domain Model that is a tree of Composite Entities with attached Business Rules.  The Business Rules entities use XPathNavigator to negotiate the structure of the model.  We have defined an abstract type system for the attributes so that that can be treated polymorphically (all types may be set to a string) and may be invalid (for example an integer attribute may be set to “XXX”). Our business rules perform a selection of functions:  Providing defaults, performing calculations and providing validation.  When the rules are applied we obtain a set of rule messages that determines the result of the action.  Business functions are implemented as Facades over the model components so that the controller need only make a single call.  By using our navigator compenents we can refer to other parts of the model using an XPath expression – this makes our rules rugged with respect to changes in the structure of the model (for excample introduction of an intemediate node).

The Business Entity layer is distinct from the persistance layer – it only depends upon the database to provide the values of the primary keys which it holds as attributes.  The Pesistence Layer consists of a set of interfaces that may be implemented by a concrete implementation.  By keeping the persistance layer distinct from the model we protect ourselves from changes in the persistance mechanism.  Our reporting requirements have forced us to duplicate calculations between views and the rules.  Since we load the model from the views it is an easy task to ensure that these calculations are in step (we have a model checker that loads each business entity from the database and fires the rules – if the model and database views are in step then there will be no mesages recorded).

The closest that I have found to what we are doing is the CSLA.NET.  The big difference is that CSLA deals in terms of a collection of “broken rules” and unifies the persistance and data access objects.  It seems to provide no core functionality for implementing business functions other than validation and authorisation.

The Microsoft UIP seems to implement the Model View Controller pattern.  This is a very heavyweight solution and seems to have reduced the model component to little more than a data container.

The Microsoft Validation Application block seems to be heading in the same direction as the business rules approach that we have been taking.  Again this stops at validation (no defaults or calculations) and may only validate a single object.

Recently I have added some XML serialization/deserialization code to an object model library that I have been working on.  In order to create the objects a Factory object is used to create the objects.  The library implements the base class and is supplied a delegate that allows the application to supply the objects.

One of my colleages commented that this did not seem to be a Factory object.  This is when I described it as a “Factory Gate”. The idea is that if the object comes out of the “Factory Gate” you don’t care if it was made there or bought in from outside and sold on.