Thinking of (DDD) warehousing
Why do we need warehousing? Domain objects (typically aggregate roots) are created to last persisted to the database, which requires dealing with the database, so that we need something like the database access layer to manage the domain objects. Is that why we can design something like the DAL layer to manage objects? Yes, but there is a difference in design, that is, we do not want the upper layer as the application tier directly access the data, all of our operations should be around the domain object, so we also designed the warehousing interface in the domain layer, and then put the implementation of warehousing in the infrastructure layer. Such design patterns are common and are commonly used for decoupling. But warehousing does not handle transactions, transaction processing we generally hand over to unitofwork, there are about Unitofwork introduction you can refer to my previous article unitofwork and its application in ABP.
ABP in the design of warehousing ideas, in fact, is also very simple, is to provide domain objects of some common database operations, the general storage of the object is the aggregation of the root, but the ABP does not strictly distinguish the aggregate root, it is simple to all objects as the aggregate root, this design is also seen in NOP. Below I was drawing a class diagram of the ABP warehouse design.
In this class diagram we can clearly see a few:
1, storage design significance, some people say I use EF development dbset<t> is actually a warehousing ah, why do I need to redefine a repository? The answer is obvious in that we may not be sure that we will use other database access frameworks such as NHibernate or MongoDB later in our project. So if I design irepository this interface, if I need to use MongoDB in my project someday, then I can inherit irepository to implement a Mongodbrepositorybase class.
2, abprepositorybase this base class GetAll return is Iqueryable<t> but IQueryable returns a query parser, not a result model. So we have no way to determine what the getall is going to return, there is no way to unit testing and so on. This question has been before the cricket blog repository back to IQueryable? Or a IEnumerable? In the discussion, interested students can refer to the next ha. The general strict DDD is not a direct return to IQueryable, but it doesn't matter if you are not a strict ddd. For this I specifically refer to the next netfocus of the enode of the case forum, specific to see the blog Enode Introduction and various resources summary (continuous update in ... Let's take a look at how the Netfocus expert designs it. Because the forum is not very familiar, I only found the account index warehouse design.
123456789101112131415161718 |
namespace
Forum.Domain.Accounts
{
/// <summary>
/// 账号索引信息的仓储接口,用于存储账号的唯一索引信息,实现账号名称的唯一性约束
/// </summary>
public
interface
IAccountIndexRepository
{
/// <summary>根据账号名称检索账号索引信息
/// </summary>
/// <param name="accountName"></param>
/// <returns></returns>
AccountIndex FindByAccountName(
string
accountName);
/// <summary>添加一个账号索引
/// </summary>
/// <param name="index"></param>
void
Add(AccountIndex index);
}
}
|
Next is the infrastructure layer implementation approach
12345678910111213141516171819202122232425262728293031323334353637 |
namespace
Forum.Domain.Dapper
{
[Component]
public
class
AccountIndexRepository : IAccountIndexRepository
{
public
AccountIndex FindByAccountName(
string
accountName)
{
using
(
var
connection = GetConnection())
{
connection.Open();
var
data = connection.QueryList(
new
{ AccountName = accountName }, Constants.AccountIndexTable).SingleOrDefault();
if
(data !=
null
)
{
return
new
AccountIndex(data.AccountId
as
string
, accountName);
}
return null
;
}
}
public
void
Add(AccountIndex index)
{
using
(
var
connection = GetConnection())
{
connection.Open();
connection.Insert(
new
{
AccountId = index.AccountId,
AccountName = index.AccountName
}, Constants.AccountIndexTable);
}
}
private
SqlConnection GetConnection()
{
return
new SqlConnection(ConfigSettings.ConnectionString);
}
}
}
|
From the above we can know that it uses the data access technology is dapper, not EF, it also has no IQueryable design, need to find what, such as Findbyaccountname, this is strictly in accordance with the DDD model of the warehouse design. This design and ABP design have advantages, look at the project needs it. At this point my warehousing also summed up here, I am also a beginner of ddd, may have some understanding is not in place, hope to learn from each other to grow together. Blog Park has a lot of similar articles, this is mainly designed to ABP related, as an ABP series of an article.
Reference article:
Http://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html
Http://www.cnblogs.com/xishuai/p/repository-return-iqueryable-or-ienumerable.html
Http://www.cnblogs.com/jesse2013/p/ddd-repository.html
Thinking of (DDD) warehousing