N-Tier Development with Model-View-Presenter and Testability (Part 2)
N-Tier Development with Model-View-Presenter and Testability Series
Part 1 - Intro
Part 2 - Tiers Overview and Business Tiers
Part 3 - User Interface Tiers
Well, this is the second part on this multi-part article. In this part we´ll see the different tiers, their interactions and how they are or are not coupled to each other. Let´s check a picture that shows all the tiers and how the abstraction level and cost to change the contract relate to each of them.
We´ll start from the more abstract tier, the Data Store Tier. This one is an old friend of every developer with a little experience in the development of Enterprise Applications.
Data Store Tier
This tier is responsible for keeping the data of your application in a physical medium like a hard disk drive. This tier is a very hard one to implement successfully and as such is one of the likeliest to be bought from a well-known vendor. This tier can be turned into a product because of its high level of abstraction. This is the tier with the greater abstraction in our application. You can have anything in this tier as long it´s in the form of tables, views and every single other object that the product offers you.
Since this is the most known tier of them all, I won´t explain it any further. Just keep in mind that this is the tier with the tables, views, procedures and everything else in a Database Management System (DBMS) that your application needs.
Persistence Tier
As I explained in the Data Store Tier data is stored in a relational manner, so data is actually stored in MxN matrixes called Tables with M being columns and N being rows.
Since we are developing in an object-oriented paradigm we have the following issue: how to translate Tables and other DBMS objects to Object-Oriented objects?
That´s the task of Object-Relational Mappers, and I´m not talking about the traditional ORM´s like NHibernate or Gentle (and now ADO.Next). I´m talking about ORMs in a broader sense as in any layer of code that maps Data Store objects to Business Objects.
This tier is usually responsible for handling transactions, SQL generating, Database Parameters and all other Database-related operations. This is a really good thing to do since by doing this we decouple our Business Objects from their actual implementation (the Database Tables).
Business Objects Tier
One of the goals we have when building N-Tier applications that are object-oriented is cohesion, and we´ll struggle to achieve functional cohesion (check part one). That´s why this tier is so important. This is the tier that defines our functional areas for the application.
The business objects are our strongly-typed smart data repositories. Now let´s see what that means:
- Strongly-typed - The business objects have properties with primary types and properties that relate to other objects. So you don´t have to deal with nothing like DataRow["Column"] and then cast it to the right type. It´s already typed and all the work to map the DBMS table to the business object is done for you by the Persistence Tier. Strongly-typed objects go a long way in reducing format and null-reference very common errors.
- Smart - The business objects are smart in the sense that they tell our upper tiers (and the persistence layer at times) a lot about how they should be used. You can do this in many forms. I´d suggest trying to do it declaratively through Attributes. I use regularly attributes for mapping the properties to columns in the table (depending on the ORM) and for validation (telling that a given property is required and has a max length of 50, for instance), but the applications for the smart business objects are huge. You could build a whole notification system for modified properties in your business objects tier.
- Data Repositories - The business objects are our unit of trade. They are the structures that´ll cross the boundaries of the other tiers. So the picture above is not "EXACTLY" correct, since most tiers will be coupled to the Business Objects tier. Note that this coupling is a weak coupling. By weak coupling I mean that if the contract doesn´t change, that is, no property is renamed or removed, you won´t have to change the coupled tiers. That´s why I suggested decorating your objects. If you rely on decoration, then you can change your business objects tier with minor to no issues on the upper tiers.
Examples of Business Objects: Customer, Project, Role, Order, OrderDetails, etc.
Business Rules Tier
This is the tier that contains our business domain logic. This is actually the core of your application. I recommend very strict standards on what refer to code analysis, code coverage and software metrics. A well-built Business Rules tier goes a long way in making an application maintainable and stable.
The Business Rules are actually classes responsible for performing the manipulation of the Business Objects. Very good samples of Business Rules are CustomerManager, ProjectManager or OrderManager. These classes usually contain methods like GetCustomerByName(string name), GetProjectsByPeriod(DateTime startDate, DateTime endDate) and SaveNewOrder(Business.Objects.Order order, bool verifyInventoryLevels). Even though these methods are fictitious you´ll probably recognize the likes of them from previous applications.
It´s important to notice also that whenever possible this tier should work with business objects and not with primary types (as is the case of the SaveNewOrder method, that receives a order object). This is very good since it decreases the complexity of this layer. The complexity is reduced because as stated above the Business Objects are strongly-typed, so in the SaveNewOrder method you won´t receive a DataRow that has a dictionary of key-indexed properties that you don´t know at design-time if even exist.
As the Business Objects tier this is a very abstract tier. Not as abstract as the Data Store or Persistence ones, since this and the objects tier are both specific to this application´s business domain. They are abstract, though, in the sense that you can easily reuse them both if you are exposing your business logic as services, as an example. Another good example is the creation of a windows service that´ll use some of your business tier´s logic. No problem, since we got the exact level of coupling that we needed.
Conclusion
Hold on, this is not the conclusion of the series! This is just the conclusion of this part, since it´s becoming big again!
In this part we saw that our business tiers, both objects and rules, are really the core of our applications. Needless to say that being the core this is where you want to make sure that NOTHING is wrong by achieving a very-high level of Code-Coverage, be positive that your classes are well organized in a way that they achieve high-cohesion and that this tier is robust, meaning that it won´t allow mischief.
In the next part we´ll check out the Interface Rules, MVP and Presentation tiers. We´ll see then how to achieve high quality in our applications through the use of software metrics, code analysis and code coverage of unit testing.
Hope to hear some comments soon.
#99