Сначала я использую Entity Framework Code, но следующая концепция одинакова ( для нетривиальных проектов ):
Я всегда держу свои классы DAL вне своих реальных бизнес-уровней.Таким образом, это уменьшает влияние изменений БД на ваше приложение.Я никогда не использую классы DAL нигде, кроме своего проекта DAL.
В моем текущем проекте используется DDD, любая компоновка похожа на следующую (очень упрощенно):
MainApp
MainApp.Domain
|...IRepositories
|...AggregrateX
|...AggregrateY
MainApp.Dal
|...Models
|...Repositories
- MainApp - Может видеть домен, но не DAL
- MainApp.Dal - может видеть домен, но не MainApp
Методы хранилища DAL используют AutoMapper:
public Customer Get(int customerId)
{
using (var context = GetContext())
{
var entity = context.Customers.Where(x=>
x.CustomerId == customerId).Single();
return Mapper.Map<DtoCustomer, Customer>(entity);
}
}
public void Save(Customer customer)
{
using (var context = GetContext())
{
var entity = context.Customers.Where(x=>
x.CustomerId == customer.CustomerId).Single();
Mapper.Map(customer, entity);
context.SaveChanges();
}
}
Таким образом, допускается полное разделение между моими бизнес-классамии мои настоящие объекты DAL / DTO.Теоретически он позволяет изменять весь бэкэнд, не затрагивая бизнес-логику.Что я не показал, так это то, что я также гарантирую, что доменные / бизнес-объекты никогда не будут видны на уровне представления, когда я сопоставляю модели ввода / просмотра, а не через фасад.
По сути, у меня остается доменный уровень, содержащий всю бизнес-логику, которая не заботится о том, что ее использует, как она заполняется или как она сохраняется, и слой DAL, единственной целью которого является популяция.и постоянство моего домена / бизнес-классов.
Однако это действительно имеет смысл только для крупных проектов.Я бы просто использовал классы DAL для тривиальных / небольших проектов.