In this part, I will start the implementation of the middle tier, and if you want some background, please see the previous parts:

The implemented architecture is published on CodePlex in a project called KISS Architecture, and this means that you can access the full source code as well as discuss it, come with suggested improvements, etc. As I walk you through the creation of the architecture, I suggest you keep the source code handy to check out more details.

With the data tier in place, I'm ready to create the middle tier, and I start by creating a plain class library named Kiss.Domain which will hold my business domain classes. I add a service reference to the data service created in the previous part (5) of this blog series, and get the complete entity data model through the generated proxy class. Then I create a plain class named OrderDomain.cs and add the following code to it:

It implements three common methods for getting a list of customers for a specified city, getting a specific customer by identity, and for updating a customer. Note that we in the list query method (GetCustomersByCity) can use LINQ to query the data service, and if you debug the code and check out the value of the query variable (q), you will see the actual query (REST) URI generated. LINQ is also used in the second query method (GetCustomer), but here in an alternative format (and with a lambda expression). Note also how simple the code is to update a customer using the data service. I have intentionally left out the other CRUD operations (insert and delete) as they should not be to hard to figure out, and don't add much to the architectural discussion.

With this in place, you see how easy it would be to move the data service to another location (like the cloud), by simply changing the URI. Likewise, the switch between online (to the server or cloud) and offline (to a local data service) would be as easy. Unfortunately, as the ADO.NET Data Services is not yet available on Windows Mobile (yet), we need to accomplish something similar in another way (which I will show in a later part of this blog series).

In the next part, I will implement the services tier.

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.