.net - converting POCO entity to business entity

Question

I am willing to integrate the entity framework as my data layer.

I followed articles and generated poco entities using this tutorial: http://blogs.msdn.com/b/adonet/archive/2010/01/25/walkthrough-poco-template-for-the-entity-framework.aspx

I have my own business objects. Here is my business object Brach:

public class Branch
{
    public long BranchId { get; private set; }
    public string BranchName { get; set; }
    public string BranchCode { get; set; }

    public Branch() { }

    public void InsertBranch(Guid companyId)
    {
        using (var ctx = new Entities.Entities())
        {
            var branch = new T_STF_BRANCH() //This is generated POCO object
            {
                company_id = companyId,
                branch_name = BranchName,
                branch_code = BranchCode
            };
            ctx.T_STF_BRANCH.AddObject(branch);
            ctx.SaveChanges();
        }
    }

    public static IList<Branch> GetBranchesList(Guid companyId, long? branchId,
        string branchName)
    {
        using (var ctx = new Entities.Entities())
        {
            var branchs = ctx.T_STF_BRANCH.Where(x =>
                x.is_deleted == false &&
                (branchId == null || x.branch_id == branchId) &&
                (branchName == null || x.branch_name.Contains(branchName))).ToList();
        }
        //HERE I NEED SOMEHOW CONVERT THE POCO ENTITIES INTO MY BUSINESS ENTITIES...
    }
}

I don't know how to convert the POCO entity into my business entity.
Where should I put the conversion from POCO and to POCO?

Answer 1

IMHO this is too complicated. Why do you have POCO entity for persistence and separate object for working with data loaded into POCO entity? Sounds like your application is over architectured.

ORM means object relational mapping. It means mapping between relation world and object world. Usually it can be also translated as mapping between database and your business objects. So you should use your POCO objects as your business objects. That is the whole meaning of using POCOs. If you don't want to use them as business objects you don't need them and you can use default entity objects directly.

If you want to use POCOs as business object simply let EF generate those POCOs for you and add partial class to each POCO defining your methods.

Btw. your business object actually looks like implementation of Active Record pattern. If you want to use this patterns perhaps you should check Windsor Active Record which is based on top of NHibernate.

Edit:

Well. You can use your classes instead of generated POCO entities.

One way is to give up with EFv4 and EDMX and check new EFv4.1 and its new fluent API (aka code-first) for mapping. This is whole for separate question or simply use search here on SO.

You can do that with EDMX as well. There are some basic rules which you have to follow to make this work because this whole is done by naming conventions. Because you already have classes you must modify this in EDMX file so that conceptual model is the same as your business objects:

• Every business object which have to be saved or loaded must have entity in conceptual model
• Entity must have the same name as the business object. You must also correctly set up the entity in property window (abstract, access level and base entity must be the same as in your business object)
• Every stored property in the business object must have a property in the entity in conceptual model. Again you must correctly set up each property (getter and setter accessibility, type, nullable, etc).

EDMX consists of three layers:

• SSDL - description of the database. This is almost always generated and you can't modify it directly in the designer.
• CSDL - description of entities which must be the same as your business objects. This is what you modify in the designer. You can rename the fields as you want.
• MSL - the mapping between SSDL and CSDL. If you open context menu on any entity in the designer you will see Table mapping. It will open a window with definition of mapping between CSDL and SSDL.

These are base rules but because you already have business objects you will most probably find situations where it will be hard to map it. The best way is simply to ask for that concrete issue. It will most probably be about some complex properties, navigation properties or inheritance.