In the previous parts of this series, we have discussed the changes that affect the architecture design. It's now time to conclude what this all leads up to architecture-wise, and we propose that the architecture should look something like this:

Most of the fundamental parts (three tiers, common services, etc), and even many of the more specific (service interfaces/agents, data access, business entities, etc) are exactly the same as in the Application Architecture for .NET that I've mentioned before in this series of blog posts.

Note that a significant change is the merge of the lower part of the middle (business services) tier and the bottom (data services) tier. As we've outlined before, this is where the business logic and its data comes together in a nice mix called the business domains. With technologies like LINQ to SQL and WCF, most (if not all) of the data services tier are actually created using code generation. This means that any changes made to the different sources (data sources and services) can be captured by regenerating the code. The tools support is actually prepared for this kind of evolution in the integration between systems, and a simple "Update Service Reference" menu selection is all that is needed.

Another similar change is the clear separation between the service interfaces and the business domains. Where the business domains have a clear responsibility to handle the logic and data for a certain business domain, the service interfaces (designed according to the facade pattern) has a different set of responsibilities. The primary distinction of a service interface is that it probably fulfills a specific part of the system's functionality (use case). Also, as they are the "first line of defense", they should handle things like basic security (authentication, authorization, encryption, etc) as well as secure coding techniques (parameter checking, prevent things like SQL/code injection, etc), compression, transactions, logging, etc. A consequence of the separation with the business domains is that the service can be placed in a separate assembly. This is a good thing because a service interface probably uses a number of business domains that may (or may not) exist in numerous assemblies.

Finally, the user interface parts have been renamed to align with the use of the MVC pattern, and as already mentioned in previous posts, this will allow for better testing and the use of the same user interface logic for different clients (thin Web interfaces built with ASP.NET, rich interfaces built with WinForms, WPF or Silverlight, and of course mobile clients built with .NET CF and soon Silverlight, etc).

In upcoming posts, we 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. Stay tuned!

MSDN has a number of excellent "How Do I"-videos geared towards Windows Mobile-development. Don't miss it...

I've found the following to be very useful:

How Do I: Test Unit Tests for Devices?
How Do I: Update User Interface Controls in Multithreaded Applications?
How Do I: Efficiently Query a SQL Server Compact Database Using LINQ?

This time we will look a little closer at an important change on the user interface side of the architecture. We're talking about applying the MVC pattern (or rather its variation, the MVP pattern), and even if this change is far from recent (both mentioned patterns have been around for quite awhile), the importance of applying this pattern has increased. The reason is an increased focus on automatic testing, TDD, and continous integration. By applying the MVC pattern, the bulk of the logic of the user interface (located in a "controller"), can be tested independent of the actual user interface. This, and the more traditional benefits, that you can apply different "views" (user interfaces or more general, channels) to the same user interface logic, makes the MVC pattern a common part of any modern software architecture.

If you do some browsing on the Web, you quickly find that there are many implementation of the MVC pattern, but there are not that many specific to Windows Mobile developers (although most .NET implementations should migrate without much hazzle). One great initiative was the MCSF by Microsoft's patterns & practices team, which included a solid implementation of the MVC pattern (among many other) that was migrated from various application blocks for the full .NET Framework. However, the MCSF was so solid that it took a great deal of time to learn before you could be productive. Also, the MCSF is now a bit outdated, and judging from the lack of news or updates about it, our hopes are not up.

The community (and us too) wanted something simpler, and in some projects, we have used a very simple and straightforward implementation by our former fellow MVP, Alex Yakhnin (he's now employed by Microsoft), that he published as a small blog series last fall (see part 1 and part 2). In those blog posts Alex also showed a simple solution to a very common problem when building great UX for Windows Mobile, and that is to handle the caching of forms. Loading a form is an expensive task in terms of performance, and therefore it's necessary to cache the forms in memory.

In upcoming posts, we 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.

Don't miss the MSDN WebCast: Creating Location-Aware Applications for Windows Mobile Devices (Level 300)

"More and more Windows Mobile powered devices ship with integrated global positioning system (GPS) hardware. Since Windows Mobile devices are typically used on the road, it makes a lot of sense to add location awareness to your applications. In this MSDN webcast, Maarten Struys shows you how you can make use of the GPS Intermediate Driver to access GPS information from inside managed applications. Learn how to use the FakeGPS utility to test location-enabled applications without needing access to a physical GPS device. Of course, in this session, you also see a location-aware application on a device using real GPS data."

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. 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 that I talked about in my previous part in this series.

As I already mentioned in the previous post in this series, the second major change to the classic Application Architecture for .NET that you see on the left 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). As soon as Web Services arrived, we instantly understood that this would be the future way of communication between systems. At the time when we wrote our book, the basic plumbing wasn't in place, and most had to be done by hand. Since then the basic Web Service technologies (XML, SOAP, HTTP, etc) has been complemented with both new exiting ones to enable better support for security, sessions, transactions, etc, as well as much better tools support. The beauty of Web Services is that they can open up a "locked" architecture (that can only deliver a fixed UX, like most Web sites on the Internet) to any client. That client could be anything from a custom made application to another system that simply want to use only the services and the data. This is what my series on Windows Mobile Web Services (e.g. Movie Lookup Web Service) is all about. Most of you probably agree that cool sites like IMDB, and FlightExplorer become even better when they can participate in a mash-up application to deliver greater value.

One technology that is important in this change is WCF as it builds on the good things about Web Services, and also takes the concept one more step. It's what .NET Remoting should have been in the first place, and even if it can be confusing as a consequence if its versatility, the main message is that you can do everything that you can do with Web Services and so much more (and it also performs very well). Therefore, my recommendation is to take a hard look at this technology and evaluate if it brings something that you need in your mobile applications. Just to make you more interested, it can travel over a number of transports (HTTP, TCP, Named Pipes, MSMQ, etc). However, not all of these transports are supported out-of-the-box on .NET Compact Framework yet, but a great thing about WCF is that it can be extended on multiple levels (transport, bindings, etc). What is supported though, is the ability to solve a classic problem with mobile applications: How can I communicate efficiently with a device that may be shut down and that is very hard to address (changing IP addresses, etc)? It's possible using the WindowsMobileMailTransport class that allow messages to be sent as e-mail. In combination with Exchange Server, and it's push e-mail technology (a.k.a. DirectPush or Always-Up-To-Date), this means that mobile application can be built that communicate very efficiently with the server (or another peer).

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.

Developing sites that are well suited for use from mobile devices is a real challenge. I was recently interviewed by Computer Sweden on the subject and I highlighted five key areas to stay on top of:

1. The browser
2. The web site
3. The resolution
4. Bandwidth
5. Input mechanisms

Be sure to not miss the following great MSDN-content that gets you started from the right place:

Walkthrough: Creating Web Pages for Mobile Devices

ASP.NET Mobile Web Development Overview

To continue this series that started with A New Mobile N-tier Architecture (part 1), we 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). We 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, we 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.