This is the final post in this series, and for a complete reference, here are the previous parts:

• Part 1 was a general introduction
• Part 2 outlined the architecture (tiers, etc)
• Part 3 showed the benefit of loosely coupled tiers (distribution, cloud, etc)
• Part 4 started the implementation by creating the entity data model (using ADO.NET Entity Framework)
• Part 5 published the entity data model as a data service (using ADO.NET Data Services)
• Part 6 implemented the business domain (using the data service)
• Part 7 created the service (using WCF)
• Part 8 started the implementation of the mobile client (using WCF)
• Part 9 added offline support to the mobile client (using SQL Server Compact, etc)

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.

On the upper right you see the UX of the sample client included in the architecture sample, and the functionality is that a part of a city name can be entered in the text box, and when the "Get" menu item is selected, the grid is filled with the matching customers.

Even if this series is complete, I will continue to build further on this architecture blueprint, and any suggestions on things to add are most welcome. Any other feedback, for that matter, is also welcome!

In this part, I will continue the implementation of the presentation tier for Windows Mobile, and if you want some background, please see the previous parts:

• Part 1 was a general introduction
• Part 2 outlined the architecture (tiers, etc)
• Part 3 showed the benefit of loosely coupled tiers (distribution, cloud, etc)
• Part 4 started the implementation by creating the entity data model (using ADO.NET Entity Framework)
• Part 5 published the entity data model as a data service (using ADO.NET Data Services)
• Part 6 implemented the business domain (using the data service)
• Part 7 created the service (using WCF)
• Part 8 started the implementation of the mobile client (using WCF)

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.

In the previous part (8) of this blog series, I showed how the Windows Mobile client can call a WCF service when connected to the network. However, there are a number of times when the mobile device is not connected and still need to allow the application to function. It would be really awesome if the new technologies like ADO.NET Data Services, ADO.NET Entity Framework, LINQ to Entities, etc, were available also for Windows Mobile and .NET Compact Framework, as this would mean that we could use identical code (assemblies/tiers) on the client, but unfortunately they are not (yet).

So, what is the second best solution? I still want to make use of the entities defined by the (data) service tier, and not maintain any custom entity code. Also, I want the implementation to be as simple as possible (remember the KISS principle) and make it as easy as possible to upgrade when these new technologies are available. That means that I don't want to spend time writing my own custom framework, but rather something simple that just works.

To allow local data storage, I create a SQL Server Compact database by adding a "Database File" named Northwind.sdf to the Kiss.Mobile project. To that database, I then add the same tables that our order (data) service defines (see part 4 of this blog series). I also add a plain class named Common.cs to the same project that is a singleton holding a single connection to the database.

With the local database in place and a connection to it, the code for the "Get" menu item can be changed into:

The variable indicating connection state (online) can be either manual or automatic through SystemState.ConnectionsCount. Before we take a look at the OrderHandler class, here's the updated code for the "Update" menu item:

Ok, so with that in place, here's the implementation of the OrderHandler class:

Not much happening here except that the handler make use of a helper that I wrote to take care of the plumbing. I can use the entity type and I need to define the query as plain SQL, but note that I've kept the desired LINQ as a comment in preparation for the day when it can be used. Let's look at the implementation of the helper class:

The database connection kept by the singleton (Common.Values) is used to either query or update the local database. Both methods are implemented using generics, and reflection is used to find all the attributes (fields). To optimize performance, a data reader is used for the query and a resultset is used for the update. Both methods are somewhat simplified as some extra null handling is necessary but does not add to the discussion. Using reflection is not an ideal solution, but remember that my goal is to keep the implementation as simple as possible and also that this is not a solution for the future, it's a temporary fix in the lack of the right technologies on the device. When that day comes, the helper class can be scrapped, and the handler class either updated or even replaced by something like LINQ to Entities.

In the next part, I will conclude this series.

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

• Part 1 was a general introduction
• Part 2 outlined the architecture (tiers, etc)
• Part 3 showed the benefit of loosely coupled tiers (distribution, cloud, etc)
• Part 4 started the implementation by creating the entity data model (using ADO.NET Entity Framework)
• Part 5 published the entity data model as a data service (using ADO.NET Data Services)
• Part 6 implemented the business domain (using the data service)
• Part 7 created the service (using WCF)

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.

I start the implementation of a Windows Mobile client by creating a new project of type "Smart Device Project", name it Kiss.Mobile, select "Windows Mobile 5.0 Smartphone SDK", ".NET Compact Framework Version 3.5", and "Device Application". This will allow it to run on many of the devices on the market, and still use the latest framework with new functionality. That new functionality include WCF, so let's move on by creating a reference to the WCF service I created in the previous part (7). You do that by using the tool NetCFSvcUtil that is included in the Power Toys for .NET Compact Framework 3.5. For more details on using this tool, please see A New Mobile N-tier Architecture (part 8).

Let's implement a simple user interface by renaming the automatically generated form (Form1) to MainForm, and add three controls (a Label named cityLabel, a TextBox named cityTextBox, and a DataGrid named simply dataGrid) to it. Also, add a MainMenu named mainMenu and add menu options to it named doneMenuItem, getMenuItem, and updateMenuItem. The result should look similar to the figure on the left.

With the service reference and the user interface in place, it's time to implement some presentation logic. Here's the code for the "Get" menu item:

Note how easy it would be to redirect the client to use the service in another location (other server, cloud, etc) by just changing the service URI. Also note how the definition of the entity (Customer) have come all the way from the data service without any manual coding anywhere, and when it is changed, it's simply a matter of updating the service references in all tiers. The observant will note that the List<Customer> return value of the service is transformed into a plain array when serialized by WCF, but if a list is preferred, this code could be used:

The code for the "Update" menu item looks like this:

It first takes the first row in the grid, and adds an "X" to the City attribute. Then the service is called with the updated entity instance (customer). It can't be much simpler than this!

In the next part, I will continue the implementation of the Windows Mobile client by adding offline support.

In this part, I will continue the implementation of the middle tier by publishing a WCF service, and if you want some background, please see the previous parts:

• Part 1 was a general introduction
• Part 2 outlined the architecture (tiers, etc)
• Part 3 showed the benefit of loosely coupled tiers (distribution, cloud, etc)
• Part 4 started the implementation by creating the entity data model (using ADO.NET Entity Framework)
• Part 5 published the entity data model as a data service (using ADO.NET Data Services)
• Part 6 implemented the business domain (using the data service)

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.

It's time to create the service, and I do that by creating a new project of type "WCF Service Application" and name it Kiss.Service. First I add a reference to the Kiss.Domain project, and then I rename the automatically generated interface to IOrderService.cs. I change its code to...

...and make sure all references to it is refactored (there are a number of places, like in the Web.config file). Then I rename the generated service class to OrderService.cs and update its (references and) code to:

This is the actual implementation of the service that implement the interface mentioned above, and each method simply use the domain class to do its work. The decoration (attribute) of the service class is needed to make the service available for a Silverlight 2 client. Even if no such client exist for Windows Mobile yet, this is a good measure to prepare for the future.

Another similar measure is to include two more files in the service project, and the first is clientaccesspolicy.xml and the second is crossdomain.xml. The purpose of these files is to make the service available for applications that make cross domain calls, and the first is specific to Silverlight and the second is used by Flash applications, among others. Here is a sample clientaccesspolicy.xml file...

...that allow any client to access the service. A final measure that is necessary for both Silverlight and Windows Mobile WCF clients is to make sure that the service use the basicHttpBinding, and here is an extract of the Web.config file:

In the next part, I will start implementing the Windows Mobile client.

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

• Part 1 was a general introduction
• Part 2 outlined the architecture (tiers, etc)
• Part 3 showed the benefit of loosely coupled tiers (distribution, cloud, etc)
• Part 4 started the implementation by creating the entity data model (using ADO.NET Entity Framework)
• Part 5 published the entity data model as a data service (using ADO.NET Data Services)

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.

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:

• Part 1 was a general introduction
• Part 2 outlined the architecture (tiers, etc)
• Part 3 showed the benefit of loosely coupled tiers (distribution, cloud, etc)
• Part 4 started the implementation by creating the entity data model (using ADO.NET Entity Framework)

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)...