In this part, we will get more practical by showing how the first parts of this new mobile architecture looks in code, and if you want some background, please see the previous parts:
- Part 1 was a general introduction
- Part 2 talked about the changes in the lower tiers (logic + data, LINQ2SQL)
- Part 3 discussed the changes in communication (WCF)
- Part 4 covered important stuff in the user interface (MVC)
- Part 5 summarized the theory and outlined the new architecture
The implemented architecture is published on CodePlex in a project called Windows Mobile Architecture Blueprint, 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, we suggest you keep the source code handy to check out more details.
Ok, let's start building the architecture from the ground up! To make things really simple (remember the KISS principle), we have started with a plain class library called Blueprint.Domain where we will keep my business domains. My first domain will be covering a small part of the classic Northwind database. I started by creating a LINQ2SQL data context called Northwind and dragged two of the Northwind tables into it (if you're like me, and don't have the Northwind database installed, you can get it here) as you can see on the right (note that we have removed the Picture field in the Category table to save bandwidth).
When that is done, a neat trick that will come in very handy is to select Properties on the design canvas of the data context and set Serialization Mode to Unidirectional. By doing this simple task, the code generated for the data context will include the necessary decorations (attributes) to make the data context ready to be published by WCF. If we look at a stripped version of the generated code (in Northwind.designer.cs)...
public partial class NorthwindDataContext : System.Data.Linq.DataContext
{
[DataContract()]
public partial class Category
{
[DataMember(Order=1)]
public int CategoryID
{
...you will see that each class (entity) has a DataContract attribute, and each field (attribute) has a DataMember attribute. These attributes will be use by WCF when the entities are communicated.
In the code above, please also note that the generated class for the data context (NorthwindDataContext) is declared "partial" which perfectly matches our intention of implementing the business logic in a parallel class. By creating such a class (Northwind.cs), and putting in some simple code like this...
public partial class NorthwindDataContext
{
public Category[] GetCategories()
{
return Categories.ToArray();
}
}
...we have implemented the first (however sparse) service into our first business domain, and the functionality is that it returns the list of all categories. Note that behind the scenes, LINQ comes into play, and to show a more obvious example, we can do this instead...
var q = from c in Categories select c;
return q.ToArray();
...and this will create the same result as the code above. Worth mentioning already is the fact that even if the Category entity holds a relation to all products in that category, those child entities are not loaded by default. This is a good thing as you probably don't want to load all products with all categories, but when you want to load related entities, you can do this by explicitly call...
var q = from c in Categories select c;
Category[] categories = q.ToArray();
categories[0].Products.Load();
...to load all the products for the first category. There are some other options for controlling how related entities are loaded, but it's out-of-scope for this blog post. In future posts in this series, we will cover more parts of the architecture blueprint implementation.