LiteMDA Design Version 0.2

---- A top to bottom MDA/ORM design

Objective:

•   High development efficiency
•   Excellent extensibility
•   Thinking in OO/AOP/C# 2.0
•   Be easy to use

1.         User Interface (UI) Viewpoint

Business Objects (BO) can only be constructed by Business Object Factory (BOF) through Business Object Interfaces (BOI).

The forms of the UI are not restricted. They can no matter be web pages, windows forms or any other modern ways like web services and so on.

All the details below UI layer are completely transparent to UI layer programmers. Things that can be seen at UI layer are only the transparent BOI instances constructed by BOF or other BOI instances, and the Domain Objects (DO) as BOI instances’ parameters and return values.

2.         Business Logic Layer (BLL) Viewpoint

By now, although the word - “MDA” here means Model Driven Architecture as its traditional meaning, what be directly used or benefited from the model are still only the static DOs needed to be persisted and the associations of DOs, such as inheritance, aggregation, composition and so on, which means only the static attributes’ definition of the DO model benefit our framework, all the methods of DOs or the other information that can be provided by the model are being ignored. So the format of the DO Model can be any model format that can be used to describe static class objects with attributes and class objects’ associations. For example, E/R Model, UML Model is the two most common suitable model formats. To decouple our framework’s dependency to the model format, we defines an Intermediate Model Schema as the base DO Model format, which means all the models in other format should be converted to the intermediate model format first.

The tools provided by our framework can help you generate the basic Domain Object Interfaces (DOI) and DOIs’ default implementing source codes automatically. You must include these auto-generated codes in your projects based on our framework, and generally, you should not modify them manually. Do not modify the auto-generated codes seems not easy before, but since C# 2.0, there is a new useful keyword – “partial” that make it possible for you to write codes for even a single class into several .cs source files, so we can keep the auto-generated codes not be modified and write our custom codes for the same class in separated source file. This is one of the reasons why I say this framework is thinking in C# 2.0. In this way, even the model is changed and we have to regenerate the some source codes, but it elegant that the custom codes written in separated source files will not be impacted by this kind of situations.

The BLL is the most important and most of the work that programmers should do in your project based on LiteMDA is in BLL. In this layer, programmers operate Domain Objects to complete business logics and expose interfaces that permitted to be use in the UI layer to BOF. Only exposed interfaces can be referenced by BOF, and then BOF can construct BOI instances for UI layer. The mapping from the BOIs to their implementing can be profiled in specified xml configuration files. In these files, in addition, you can not only add static injection options for BOI but also add dynamic waving options for BOs, too. This is the so called thinking in AOP.

For transaction, in LiteMDA design Ver 1.0, I design to make all the transactions in BLL setting in Xml, but it seems not easy to implement so in this design ver 0.2, I will not use such a transaction configuration file any more. Instead, all the transactions will be directly write in the custom Bos. As in traditional way, I will provide a Transaction Factory to construct all the transactions. And each BO and DO has a transaction attribute, if this attribute is set to a transaction instance, then operations will be in the specified transaction.

3.         Persistence Layer (PL) Viewpoint

PL is a transparent layer. It provides transparent O/R Mapping from DO Model and DOs’ associations, such as inheritence, aggregation, composition and so on, to Relation Database (RDB) if your system use RDB, or it also can help DOs’ persisting to Object Oriented Database (OODB). PL provides two methods, “Save” and “Load”, for each DO. “Save” does writing and “Load” does reading. PL also provides generic base collection help classes for collection-kind DOs’ persistence. This function will be realized elegant through the new gneric support of C# 2.0. Although I plan to implement a ORM component for LiteMDA, I will also write some persistence adapter for third party persistence framework such as Nhibernate and NIbatis.

Say something about “Save” and “Load”. In an article of idior, he critisize the “Save” and “Load” design in EJB, but I don’t agree with him, I think, “Save” and “Load” is a good design, they are the basic elements of Object Oriented Perstsence Design. And I will prove this in the LiteMDA implementing.