In this part, I will continue with the implementation of the data service using ADO.NET Data Services, 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.

Now it's time to publish the entity data model (OrderModel.edmx) that we created in the last part (4) of this blog series, and that is done by adding an "ADO.NET Data Service" named OrderDataService.svc to the data tier assembly, Kiss.Data. The modifications necessary to this service class is trivial, and involves specifying the type of the data model (object context, in my case OrderEntities) and making the complete model available to anyone. The resulting code looks like this:

Amazing as it sounds, the data tier is now ready to be used, and we can start querying the database through the newly built data service. For example, if we go to http://localhost:1111/OrderDataService.svc/CustomerSet('ALFKI'), we get the following result (somewhat simplified)...

...and this allows us to query the complete data model through a RESTful interface. Note that you may have to turn off the automatic feed formatter included in Internet Explorer 7 to see the resulting XML (in ATOM format), and you do that by selecting Tools > Internet Options > Content > Feeds Settings, and uncheck "Turn on feed reading view".

In the next part, I will start implementing the middle tier.

In this part, I will get more practical by showing how the first parts of this architecture looks in code, and if you want some background, please see the previous parts:

I'm continuing the series that started with part 1 and part 2 by talking more about the changes in a modern mobile multi-tier architecture. This time I will talk about the benefits of having loose coupling of the tiers.

For years, actually since Web Services started to be used, we have had a loose coupling between the presentation and middle tier. The effect has been that the system can be physically partitioned on different machines and even on either side of a firewall. Effectively creating many options for separating presentation from services, like using external services or even outsourcing services. It also allowed the outsourcing of the presentation tier unrelated to the location of services.

With the data tier, it was more difficult. Even if many applications also physically separated the services from the data tier, it was often problematic due to security issues (like opening up odd ports in the firewall to allow database traffic). With a technology like ADO.NET Data Services, it becomes easier to deploy the data tier separated from the services tier. That is not only a benefit for deployments on the server side, but it also opens up the ability to use an external data provider.

One interesting initiative by Microsoft is what they call services in the "cloud" (i.e. on the Internet), known as Azure (note the color of the cloud in the diagram figure below), and it means that we will have a new option for outsourcing the different tiers. With an upside-down view of the tiers (users at the bottom and the data tier on top), the following figure shows a number of available options:

Starting from the left, we have a stand-alone application (A) with all three tiers running locally on the client. The next, is the traditional client/server application (B) with a fat client only hosting the data on the server. This option has not been used much the last couple of years, mostly because of the lack of simple data access, but will probably be more common in application using Silverlight 2 and ADO.NET Data Services. Next, is the typical fat client application (C) using server-side services, and then we have a normal Web application (D). The first option that use the cloud (E) is an application that make use of a cloud-hosted data service (like SQL Data Services), and the last two options also host the services (F) and even the presentation (G) tier in the cloud (using .NET Services). Of course, several of these options can be combined, and an example is an application hosted in the cloud (G) that can also be run offline (A) when the client doesn't have a network connection (a common scenario for a mobile application).

In the next part, I will start implementing the architecture that enable these options.

To continue this series that started with KISS Architecture (part 1), I will now talk more about a modern mobile multi-tier architecture. Because a picture always says more than a thousand words, let's start with a classic one.

This image should be familiar to anyone who read the Application Architecture for .NET from back in 2002. Interestingly, the Microsoft's patterns & practices team are working on a new version of this guide called Application Architecture Guide 2.0 that is already in its second beta (there is also a specific pocket guide for mobile architectures). Building on the discussions in that guide, I have taken the old diagram (because I like the colors) and created an updated version with a small modification. The modification is related to the placing of the business entities, that I think belong in the data tier. The main reason for that is that the ORM technologies (in my case, LINQ to Entities or ADO.NET Entity Framework) take care of defining the business entities. For more details on multi-tier architectures, please read the guide, it's a great resource.

A nice addition to the traditional diagram is to show how other systems ("External Systems") access my system's services that are published as service interfaces with WCF, and that is exactly how other systems ("Services") are accessed by my system.

However, the biggest changes compared to my previous architecture blueprint are probably in the data tier. Even if I was a big fan of LINQ to SQL, the ADO.NET team have announced that the long-term plan is that in ".NET 4.0, LINQ to Entities will be the recommended data access solution for LINQ to relational scenarios". Therefore, I now use LINQ to Entities (ADO.NET Entity Framework) in the data tier.

However, the changes in the data tier doesn't stop there. Another (probably even bigger) change is that the data tier is now made loosely coupled for the first time. Many attempts have been made in this direction (SQLXML to mention one) before, but I think that this time Microsoft got it right with ADO.NET Data Services. In short, it's a way of accessing data through a simple RESTful interface over HTTP using formats like ATOM and JSON.

Even if this means that it becomes very easy to access the data source directly form the presentation tier, it doesn't mean that a sound architecture should use or even suggest such nonsense. It may be interesting and fun for quick demos, but doesn't belong in any serious enterprise solution - mobile or not. Therefore, the thinking that I introduced in A New Mobile N-tier Architecture (part 2) about keeping the data and logic as logically bound together as possible (in what I call domains) still holds. I strongly believe that the data should only be accessed through the logic.

In the next part I will talk about the benefits of having tiers that are loosely coupled.