To continue this series that started with A New Mobile N-tier Architecture (part 1), I will talk more about the changes in a modern mobile multi-tier architecture.  We can see that the most important changes are happening on two levels, and the first is the tighter bond between the business logic and it's data.

Before, we had a distinct separation in the two lower tiers between the logic and the data. The thinking was that the data services could be used by several parts of the business logic to handle basic CRUD operations. This is shown in the Application Architecture for .NET from 2002 that you see on the left where the business logic and the data access was divided into the lower two of the classic three tiers. However, the problem was that data without logic is almost useless, and even if the logic existed (in various business components) the natural relation with the data was not manifested.

The other change is the change in the way that clients exchange information with the server (or more general, the way that two systems or peers exchange information), and that will be the focus of the next part in this series.

If we look at technologies like LINQ and specifically LINQ2SQL (LINQ to SQL) the traditional separation between the logic and the data is encouraged. On the right you find an illustration what is happening in the lower two of the traditional three tiers. The observant note that the business entities is moving down to he data tier (where they belong), but more importantly, the two tiers are actually moving together. With a LINQ2SQL, the business logic can be implemented in the same data context (the ORM) class (by using the ability to define partial classes). I would like to call these merged entities domain components as they define and handle both the data and the logic for a specific business domain. So, the service interface (facade) would actually work with a number of domain components to deliver functionality to its clients. The challenge is how the functionality (logic + data) is spread among the domains to make them a perfect tradeoff between versatility and reusability. The bigger, the more versatile, the smaller, the more reusable. The general message is probably to keep them small and distinct.

In upcoming posts, I will continue with more of my thoughts on the changes in mobile architecture, and of course also some code samples to show the theory in practice.