Model of domain design congestion, repository object injection

Working in contact with a number of project teams, they in the actual project development, Domain object of the anemia model design, or the main application of the paradigm. The reason for this is that in the anemic model model design, all the business logic involved in the persistence is encapsulated in the domain service layer or the Application service layer, so the package eliminates the controversy over whether a business logic is built on the Domain Services layer or the domain model layer. Make layering simple, easy layering is also easy for team collaboration development and testing.

Of course, there are a lot of problems brought about by this.

One, the semantics is unclear;

Second, the business complex prone to bad design, resulting in business duplication of implementation, bug piles;

Third, the transactional business requirements and multi-task concurrency check error-prone;

Iv. demand growth and change bring about rapid growth in development costs (this is more like process-oriented programming, more anti-OO)

These problems are not explained, I believe that some of the projects have been more or less encountered.

Writing these, in fact, can be seen, subconsciously I support the use of the congestion model. The congestion model can make the business logic very thin and full of business semantics. Constructs a crud and granular semantic implementation of entity-oriented in the domain object layer. (hand lazy, in fact, this computer does not install the IDE, you can see this link example: http://www.cnblogs.com/chenzhao/archive/2012/08/13/2636179.html)

However, there are two basic problems to be solved by using the congestion model, one is the business logic layering (this is more annoying, the time is ample to write an example); One is the repository injection of the domain object layer.

Look at the domain object layer repository injection, do not say, look at the code:

Domain object Layer
public interface IRoot
{
int ID {get; set;}

}
public interface ipersistence<t>
{
Ireposity<t> Repository {get; set;}

}
Public interface ireposity<t>: IDisposable
{
T ADD (t model);
}
public class User:iroot, ipersistence<user>
{
public int ID
{
Get
Set
}

public string Name
{
Get
Set
}

Public ireposity<user> Repository
{
Get
Set
}

public void Add ()
{
Repository.add (this);
}
}
//-----------------------

Domain Service Tier
public class Usermanageservice
{
public static void AddUser (user user)
{
User. Persistence (). ADD ();

}
}
public static Class Userex
{
public static user persistence (this user user)
{
User. Repository = new repository<user> ();
return user;
}
}
//------------------------

Domain Repository Layer
public class Repository<t>: ireposity<t>
where T:class,iroot, New ()
{

Public T ADD (T model)
{
return null;
}

public void Dispose ()
{

}
}
//------------------------

This allows the Repository object to be injected into the domain object through the service layer. Of course, you might want to use a third-party dependency injection library, but it's not required. (the wife called to eat, the code casually did not look closely, if has the mistake you to forgive more.) ）

　　

　　

Model of domain design congestion, repository object injection