Business Object Architecture

As shown in the following UML class diagram, MM .NET business objects are composed of four main classes

The main business object class (OrderDetail)
An entity class (OrderDetailEntity)
A business rules class (OrderDetailRules)
A data access class (OrderDetailDataAccess - optional)

While some frameworks wrap all of this functionality into a single class (sacrificing performance and extensibility for the sake of simplicity), MM .NET business object architecture gives far more extensibility and run-time performance for developers building real-world business applications.

Integration with MVC and MVVM

This architecture maps nicely into the Model-View-Controller design pattern as well as the Model-View-ViewModel pattern.

Composition

There is a composition relationship between the Business Object the Entity, Rules, and Data Access objects. Composition is defined in The Unified Modeling Language User Guide as:

"A form of aggregation with strong ownership and coincident lifetime of the parts by the whole; parts with nonfixed multiplicity may be created after the composite itself, but once created they live and die with it; such parts can also be explicitly removed before the death of the composite."

This is definitely true of the relationship between these objects. The Business Object has strong ownership of the Entity, Rule, and Data Access Objects.

Extensibility

In an object-oriented architecture, whenever you break out a set of functionality into a separate object you gain extensibility and flexibility.

For example, business rule objects can be used by multiple business objects or business process objects, which is important since business rules don't always apply to a single object! In addition the MM .NET business layer architecture allows you to subclass and extend business rule, business entity and data access objects to take full advantage of object-oriented inheritance.

In addition, all business object classes are marked as partial classes so you can easily extend generated business layer code without losing any of your changes!

Performance

The Rules, Entity, and Data Access objects are not instantiated at run time until they are first accessed (lazy instantiation) which translates into measurable speed increases. If you don't need to check business rules, the Rule object is not instantiated. If you don't need to access data, the data access object is not instantiated. In addition, Entity objects are light-weight objects that can be quickly passed across physical tiers of an application.