Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Tagged as

MData – The idea

, 4 Jul 2012 CPOL
Rate this:
Please Sign up or sign in to vote.
A while ago, I was playing around with the XAF framework from Devexpress, in particular with the Domain Components technology (see here and here). I was really convinced about this technology which keeps it simple to test/mock domain objects/classes. Now here is the basic idea: Instead of having a D

A while ago, I was playing around with the XAF framework from Devexpress, in particular with the Domain Components technology (see here and here). I was really convinced about this technology which keeps it simple to test/mock domain objects/classes. Now here is the basic idea:

Instead of having a Domain object Customer implemented in a concrete class Customer, we define a Customer with an interface ICustomer. In many traditional DDD implementations, where a sort of anemic domain model is used, all logic on certain entities is placed is so called services. This brings a few problems with it, especially in terms of maintenance. This is explained very well in this talk from Jimmy Bogard

The solution to this problem is containing business logic in the domain models itselve. This is a very good theory, but in practice we see that this is very hard to align with the modern ORM’s. When it comes to hosting a WCF, NSericeStack service, we want to reuse this Domain model, but not necessarily transfer all the business logic to the client/server side. This is were my idea comes in. I wanted to create an extensible platform in which a domain model is merely a contract defining which data an entity should hold, and which functionality it exposes. The concrete implementation of these interfaces is something the developer doesnt have to deal with. Those are generated at runtime by MData internals. Now one of the main problems with this approach is that interfaces typically do not contain ‘real’ code. What I mean by this is that an interface never supplies an implementation for let’s say a method (nor any other member). So to make it possible for the developper to actually write his ‘domain logic’, I created the notion of a LogicBase<T>, where T is the interface it supplies the logic for. This is a zero/one to one relationship, meaning that for one given interface (domain model) there can at most be one LogicBase implementation. If no implementation was provided, the system uses the default generic LogicBase class.

Now this blog-series will cover how I implemented the MData framework step by step, I’ll try to list the benefits and liabilities, and show some interesting use cases for this framework.

By the end of the series we will be able to write this code:

private static void Main(string[] args)
{
    //create EF CF context
    using (DomainContext t = new DomainContext())
    {
        //all CRUD operations work
        ICustomer customer = t.Customers.Create();
        t.Customers.Add(customer);

        ICustomer firstCustomerEver = t.Customers.FirstOrDefault(x => x.Id == 1);

        t.SaveChanges();
    }
}

public class DomainContext : MDbContext
{
    public MDbSet<ICustomer> Customers { get; set; }
}

In the meanwhile all code for MData is publicly accessible on github

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Pieter Van Parys
Software Developer
Belgium Belgium
LinkedIn Profile
 
I maintain a blog at pietervp.com
Follow on   Twitter

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.141220.1 | Last Updated 4 Jul 2012
Article Copyright 2012 by Pieter Van Parys
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid