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

    Comments

    Add comment


    (Will show your Gravatar icon)  

      Country flag

    biuquote
    • Comment
    • Preview
    Loading



    Powered by BlogEngine.NET 1.4.5.0
    Theme by Mads Kristensen