KISS Architecture (part 6)

by Chris 2. January 2009 16:05

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:

    namespace Kiss.Domain
    {
       
    public class OrderDomain
        {
           
    OrderEntities data = new OrderEntities(new Uri("http://localhost:1111/OrderDataService.svc"));

           
    public List<Customer> GetCustomersByCity(string city)
            {
               
    var q = from c in data.CustomerSet
                       
    where c.City.Contains(city)
                       
    select c;

               
    return q.ToList();
            }

           
    public Customer GetCustomer(string id)
            {
               
    return data.CustomerSet.SingleOrDefault(c => c.CustomerID == id);
            }

           
    public void UpdateCustomer(Customer customer)
            {
                data.AttachTo(
    "CustomerSet", customer);
                data.UpdateObject(customer);
                data.SaveChanges();
            }
        }
    }

    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.

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

    by Chris 26. December 2008 16:01

    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:

    namespace Kiss.Data
    {
       
    public class OrderDataService : DataService<OrderEntities>
        {
           
    public static void InitializeService(IDataServiceConfiguration config)
            {
                config.SetEntitySetAccessRule(
    "*", EntitySetRights.All);
            }
        }
    }

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

    <?xml version="1.0" encoding="utf-8" standalone="yes" ?>
    <
    entry xmlns="http://www.w3.org/2005/Atom">
        <
    id>http://localhost:1111/OrderDataService.svc/CustomerSet('ALFKI')</id>
        <
    title type="text" />
        <
    updated>2008-11-25T02:24:45Z</updated>
        <
    author>
            <
    name />
        </
    author>
        <
    link rel="edit" title="Customer" href="CustomerSet('ALFKI')" />
        <
    link type="application/atom+xml;type=feed" title="Orders" href="CustomerSet('ALFKI')/Orders" />
        <
    category term="Kiss.Data.Customer" />
        <
    content type="application/xml">
            <
    properties>
                <
    CustomerID>ALFKI</CustomerID>
                <
    CompanyName>Alfreds Futterkiste</CompanyName>
                <
    ContactName>Maria Anders</ContactName>
                <
    ContactTitle>Sales Representative</ContactTitle>
                <
    Address>Obere Str. 57</Address>
                <
    City>Berlin</City>
                <
    Region null="true" />
                <
    PostalCode>12209</PostalCode>
                <
    Country>Germany</Country>
                <
    Phone>030-0074321</Phone>
                <
    Fax>030-0076545</Fax>
            </
    properties>
        </
    content>
    </
    entry>

    ...and this allows us to query the complete data model through a RESTful interface. Note that you may have to turn off the automatic feed formatter included in Internet Explorer 7 to see the resulting XML (in ATOM format), and you do that by selecting Tools > Internet Options > Content > Feeds Settings, and uncheck "Turn on feed reading view".

    In the next part, I will start implementing the middle tier.

    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

    Powered by BlogEngine.NET 1.4.5.0
    Theme by Mads Kristensen