KISS Architecture (part 4)

by Chris 19. December 2008 15:59

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:

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

    As I mentioned in the first part, 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.

    Ok, let's start building the architecture from the ground up! To make things really simple (remember the KISS principle), I start with an "ASP.NET Web Application" named Kiss.Data as the data tier. In that assembly I add an "ADO.NET Entity Data Model" class named OrderModel.edmx, and add the following tables from the Northwind database (renamed Customer, Order, OrderDetail, Product and Category):

    KISS Architecture Entity Model

    If we take a look at a simplified version of the generated code (in OrderModel.Designer.cs)...

    namespace Kiss.Data
    {
       
    public partial class OrderEntities : ObjectContext
        {
           
    public OrderEntities(string connectionString) :
                base(connectionString, "OrderEntities")
            {
               
    this.OnContextCreated();
            }
           
    public ObjectQuery<Customer> CustomerSet
            {
               
    get
                {
                   
    if(this._CustomerSet == null)
                       
    this._CustomerSet =
                           
    base.CreateQuery<Customer>("[CustomerSet]");
                   
    return this._CustomerSet;
                }
            }
           
    private global::System.Data.Objects.ObjectQuery<Customer> _CustomerSet;
        }

        [
    EdmEntityTypeAttribute(NamespaceName = "Kiss.Data", Name = "Customer")]
        [
    DataContractAttribute(IsReference = true)]
        [
    Serializable()]
       
    public partial class Customer : EntityObject
        {
            [
    EdmScalarPropertyAttribute(EntityKeyProperty = true, IsNullable = false)]
            [
    DataMemberAttribute()]
           
    public string CustomerID
            {
               
    get { return this._CustomerID; }
               
    set
                {
                   
    this.OnCustomerIDChanging(value);
                   
    this.ReportPropertyChanging("CustomerID");
                   
    this._CustomerID = StructuralObject.SetValidValue(value, false);
                   
    this.ReportPropertyChanged("CustomerID");
                   
    this.OnCustomerIDChanged();
                }
            }
           
    private string _CustomerID;
           
    partial void OnCustomerIDChanging(string value);
           
    partial void OnCustomerIDChanged();

    ...we see that in the model, or object context, (OrderEntities) there is a class created for each entity (Customer) and a query (set) for that entity (CustomerSet). Also note that each of the entity classes and its members has the necessary decorations (attributes) to be serialized correctly over WCF.

    In the next part, I will look at how to publish the data model as a data service.

  • Currently rated 5.0 by 1 people

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

    Tags: , , ,

    Architecture | Chris | Compact Framework | Windows Mobile

    KISS Architecture (part 3)

    by Chris 12. December 2008 15:57

    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:

    KISS Architecture Tier Distribution

    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.

    Be the first to rate this post

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

    Tags: , ,

    Architecture | Chris | Compact Framework | Windows Mobile

    KISS Architecture (part 2)

    by Chris 5. December 2008 15:55

    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.

    KISS n-tier architecture

    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.

    Currently rated 4.0 by 2 people

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

    Tags: , , , , , ,

    Architecture | Chris | Compact Framework | Windows Mobile

    KISS Architecture (part 1)

    by Chris 25. November 2008 15:51

    In March, when I started to create a new architecture for building mobile applications for Windows Mobile called Windows Mobile Architecture Blueprint, I thought that it would be possible to use the result for a while. I was both right and wrong. I was right about some of the theory and some of the technologies, but this fall (specifically this year's PDC) has changed a lot of things. I therefore realize that it's already time for yet another attempt to create an architecture blueprint. As last time, I will start with the server side (remember, almost no mobile applications live alone), and then work my way all the way out to the Windows Mobile client.

    As you may recall from the last attempt, I'm a big fan of the KISS principle. So big, in fact, that this time I have named the architecture after this principle. The reason is that I think it's of absolute necessity that the architecture is as simple as possible (but no simpler, as Einstein said). Otherwise it will not be used, and the whole point of thinking through and implementing an architecture is that someone will actually use it. Some of the other principles that also apply are YAGNI (don't implement it until you really need it) and DRY (learn to master the difficult art of partitioning a system).

    Here are some of the technologies and products that will be used in (or suitable for) the architecture:

    • .NET Framework - the treasure chest
    • C# - my language of choice
    • Visual Studio - the worlds greatest development tool
    • SQL Server - my database of choice (on both server and device)
    • ADO.NET Entity Framework and LINQ to Entities - the way forward on ORMs (for the ADO.NET team)
    • ADO.NET Data Services - how to make data access loosely coupled
    • WCF - on discussion, this is the RPC of our time
    • WinForms/ASP.NET - traditional ways of designing UXs
    • WPF/Silverlight - the new way of designing UXs
    • Azure/Live services - a new alternative to host data, services, and applications

    To get some theory and background to the use of some of the above mentioned technologies, I recommend you read the beginning of the last series (you find links to all the blog posts in the last post). This time, I will focus only on the technologies that changed since the last time, and therefore, as an example I will not talk much about WCF and how to access WCF services from a .NET CF application (covered in parts 3, 7, and 8 in the last series).

    Just as last time, this effort will be an open source venture hosted on CodePlex with the name KISS Architecture. 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.

    Accompanying the source code will be a series of blog posts starting with this one.

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

    by Chris 14. November 2008 15:29

    blueprintuiThis 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 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
    • Part 9 showed the implementation of the user interface (MVC)

    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.

    On the upper right you see the UX of the sample client included in the architecture blueprint, and the functionality is that the combo box is filled with the categories when the application starts. Then, when a category is selected, the product names are shown in the text box below.

    Even if this series is complete, we 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!

    Currently rated 5.0 by 1 people

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

    Tags:

    Architecture | Chris | Compact Framework | Windows Mobile

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

    by Chris 31. October 2008 15:25

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

    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.

    We are now ready to consume the WCF service that we created in the previous post, and therefore we have added a new "Smart Device Project" and selected to create a Device application targeting Windows Mobile 6 Standard (a.k.a Smartphone) and the latest .NET Compact Framework (3.5).

    As the tools support is not yet in place in Visual Studio, to consume a WCF service, you need to first download and install the Power Toys for .NET Compact Framework 3.5. The tool that you are after is named NetCFSvcUtil.exe, and you use it like this...

    NetCFSvcUtil /language:cs http://localhost:5610/Service.svc

    ...and in the source code you can find a batch file (CreateServiceClient.bat) that will run this command (note that you may have to change the path to the NetCFSvcUtil utility depending on whether you're running on 32- or 64-bit). Note that the WCF service must be running when you run this command, and the out of running this batch file looks something like this...

    netcfsvcutl

    ...with the result that two files are generated (Service.cs and CFClientBase.cs). As there files are already part of the source code, they will simply be replaced and the procedure with running the batch file is the next best thing to what you would expect from integrated support in Visual Studio.

    Now, with these two files in place, we can start consuming the WCF service with code like this...

    ServiceClient.EndpointAddress = new EndpointAddress("http://192.168.0.100:5610/Service.svc/basic");
    ServiceClient service = new ServiceClient();
    Category[] categories = service.GetCategories();

    ...and the first thing we do is to set an endpoint of the service that the mobile device can reach (in this case an IP address). Then the service proxy (ServiceClient) is instantiated and used to retrieve the list of categories. Note that the business entity (Category) that was declared back in the business domain (automatically generated by LINQ2SQL, and automatically serialized by WCF) is readily available on the mobile client (thanks to the proxy we generated above).

    In future posts, we will cover more parts of the architecture blueprint implementation.

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

    Currently rated 5.0 by 1 people

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

    Tags: , , ,

    Architecture | Chris | Compact Framework | Windows Mobile

    A New Mobile N-tier Architecture (part 7)

    by Chris 24. October 2008 15:19

    I 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

    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, I suggest you keep the source code handy to check out more details.

    The next step in building the architecture is to create the service interface (i.e. the service), and therefore I have added a new "WCF Service Application" project called Blueprint.Facade to the solution that already included the business domain project (Blueprint.Domain). My first service will be publishing the very simple functionality that the business domain provides (the ability to retrieve all categories from the database). First, I have renamed the service interface to IService and the service implementation to Service (removed the "1" at the end on both), and here you need to make sure that all references are updated (four occurences in the web.config file and don't forget the one in Service.svc). The implementation of the service interface (IService.cs) can be done like this...

    [ServiceContract]
    public interface IService
    {
        [
    OperationContract]
       
    Category[] GetCategories();
    }

    ...and with a reference to the business domain project, the service implementation (Service.svc.cs) can be implemented with this code...

    public class Service : IService
    {
       
    public Category[] GetCategories()
        {
           
    using(NorthwindDataContext dc = new NorthwindDataContext())
               
    return dc.GetCategories();
        }
    }

    ...to complete the implementation of the service. When the project is built and run, the WCF is ready to be consumed, and therefore it's a good idea to remember the URL to the service as we will need it in the next post when we will look at how this service can be consumed from a mobile client application.

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

    by Chris 17. October 2008 15:14

    In this part, I 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, I suggest you keep the source code handy to check out more details.

    nwdatacontext Ok, let's start building the architecture from the ground up!  To make things really simple (remember the KISS principle), I have started with a plain class library called Blueprint.Domain where I 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 I 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, I will cover more parts of 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

    Powered by BlogEngine.NET 1.4.5.0
    Theme by Mads Kristensen