A New Mobile N-tier Architecture (part 9)

by Chris 7. November 2008 15:27

WeI will continue the more practical part of this series by showing how the 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
  • Part 6 started the walkthrough of the architecture code by looking at the business domain
  • Part 7 continued the code walkthrough with a look at the service (WCF)
  • Part 8 covered the consumption of the service with .NET CF

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.

It's time to look at how we can implement the MVC pattern in the Windows Mobile client project that we created in the previous part of this series. As we've touched on before in this series, we have built this part of the architecture on a very simple and straightforward implementation by Alex Yakhnin, that he published as a small blog series last fall (see part 1 and part 2).

As Alex, I started with the core interfaces...

interface IView
{
   
void Show();
   
void Hide();
   
void Close();
   
string Text { get; set; }
}
interface IController
{
   
IView View { get; set; }
}

...and then the interface for the main view (form)...

interface IMainView : IView
{
   
Category SelectedCategory { get; }

   
void SetCategories(Category[] categories);
   
void SetProducts(string products);

   
event EventHandler Done;
   
event EventHandler CategorySelected;
}

...which already tells us what the main form can do. It allows us to set a number of categories (to choose from, SetCategories) and it will notify when a category is selected (CategorySelected). It will also make that selected category available through a public property (SelectedCategory) and allow us to set the products for a (the selected) category (SetProducts). Finally, it will notify when the user is done with it (Done).

The implementation of the controller for the main form looks like this...

class MainController : IController
{
   
private IMainView view;
   
private ServiceClient service;

   
public MainController(IMainView view)
    {
        View = view;

       
ServiceClient.EndpointAddress = new EndpointAddress("http://192.168.0.100:5610/Service.svc/basic");
        service =
new ServiceClient();

       
Category[] categories = service.GetCategories();
        view.SetCategories(categories);
    }

   
private void attachView(IMainView view)
    {
       
this.view = view;
        view.CategorySelected +=
new EventHandler(view_CategorySelected);
        view.Done +=
new EventHandler(view_Done);
    }

   
void view_CategorySelected(object sender, EventArgs e)
    {
        Category category = view.SelectedCategory;
       
string s = string.Empty;
       
foreach(Product product in category.Products)
            s += product.ProductName +
"\r\n";
        view.SetProducts(s);
    }

   
void view_Done(object sender, EventArgs e)
    {
        Application.Exit();
    }

    #region IController Members
   
public IView View
    {
       
get { return view; }
       
set { attachView(value as IMainView); }
    }
    #endregion
}

..and upon creation, the controller saves its view, and set up the event handlers to capture event from the view. Then it make the first call to the service to get the category list which is sent to the view. When a category is selected, a string is created (I know, in a real solution it would be a StringBuilder, but this code is simpler to read) and passed to the view.

The implementation of the main view (form) looks like this...

public partial class MainForm : Form, IMainView
{
    public MainForm()
    {
        InitializeComponent();
    }

    public Category SelectedCategory
    {
       
get { return categoryComboBox.SelectedItem as Category; }
    }

    public void SetCategories(Category[] categories)
    {
       
foreach(Category category in categories)
            categoryComboBox.Items.Add(category);
    }

   
public void SetProducts(string products)
    {
        productsTextBox.Text = products;
    }

    public event EventHandler CategorySelected;
   
private void categoryComboBox_SelectedIndexChanged(object sender, EventArgs e)
    {
       
if(CategorySelected != null)
            CategorySelected(
this, null);
    }

   
public event EventHandler Done;
   
private void doneMenuItem_Click(object sender, EventArgs e)
    {
       
if(Done != null)
            Done(
this, null);
    }
}

...and here we see that the categories are loaded in a combo box which is used to determine the currently selected category, and also to raise the event when a category is selected. The products string is simply put into a text box, and a menu option is used to offer the user to exit.

To manage (can cache) the various controllers and views, we use the following singleton class...

class ApplicationManager
{
   
public static readonly ApplicationManager Instance = new ApplicationManager();
   
private ApplicationManager() { }

   
private Dictionary<string, IController> controllersCache;

   
public MainForm GetMainForm()
    {
       
if(!controllersCache.ContainsKey("Main"))
            controllersCache.Add(
"Main", new MainController(new MainForm()));
       
return controllersCache["Main"].View as MainForm;
    }
}

...and the application is kicked off like this...

[MTAThread]
static void Main()
{
   
Application.Run(ApplicationManager.Instance.GetMainForm());
}

...which concludes the walkthrough of the basic architecture! In the next post, we will summarize this series of blog posts on the architecture blueprint implementation.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

Architecture | Chris | Compact Framework | Windows Mobile

A New Mobile N-tier Architecture (part 5)

by Chris 10. October 2008 15:08

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

newarch 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 I'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, 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. Stay tuned!

Currently rated 4.0 by 1 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , ,

Architecture | Chris | Compact Framework | Windows Mobile

A New Mobile N-tier Architecture (part 4)

by Chris 18. September 2008 15:05

This time we will look a little closer at an important change on the user interface side of the architecture. I'm 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, my hopes are not up.

The community (and me too) wanted something simpler, and in some projects, I have used a very simple and straightforward implementation by my 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, 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.

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

Architecture | Chris | Compact Framework | Windows Mobile

Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen