我们是否应该在数据库层中进行投影和格式化类型的活动
本文关键字:投影 格式化 类型 活动 是否 数据库 我们 | 更新日期: 2023-09-27 18:34:45
我正在对同事编写的以下代码进行代码审查,根据我的经验,投影和格式化类型的活动不应该在数据库层完成,而应该在业务层进行。但他不相信。此数据库层用于 mvc 应用程序。
请建议我以下代码是可以的,或者我们应该始终避免在数据库层中进行投影/格式化。
public class CustomerDetails
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string Address1 { get; set; }
public string Address2 { get; set; }
public string City { get; set; }
public string State { get; set; }
public string Country { get; set; }
public DateTime PurchaseDate { get; set; }
public Decimal OrderAmount { get; set; }
//more propery...
}
public class CustomerRepository
{
public IEnumerable<CustomerDetails> GetCustomer(int customerID)
{
//get data using entity framework DBContext
IEnumerable<CustomerDetails> customer = get data from database using sqlquery;
//projection and formatting
return customer.Select
(p =>
new CustomerDetails
{
FirstName=p.FirstName.ToProper(), //extension method
LastName = p.LastName.ToProper(),
Address1 = p.Address1,
Address2=p.Address2,
City = p.City.ToProper(),
State=p.State.ToUpper(),
PurchaseDate=p.PurchaseDate.Tommddyyy(),
OrderAmount=p.OrderAmount.ToUSA()
}
);
}
}
更新:
客户详细信息是数据库实体,它通过存储过程映射字段返回。我们正在使用存储库在ORM(EF(上放置一个抽象层,这样如果我们需要更改ORM框架,它不会影响依赖层。
我的想法是,我们应该从存储库返回行数据,并且应该在服务层中完成相同数据的不同表示。
说的是,将这种代码放在哪里可能是一个设计决策,具体取决于实际情况。
此外,当使用 OR/M 框架时,我怀疑是否会有数据库层,因为任何 OR/M 都试图成为数据层本身,并且它们倾向于提供类似存储库模式的接口来查询和写入持久对象。也就是说,由于存储库是一个类似集合的接口,它将底层数据格式转换为域对象(实体(,因此似乎无论您如何称呼您的层,它们仍将是域/业务层,或者可能是服务层 - 谁知道 - 。
此外,您的代码似乎是一个存储库(!(,这意味着我们不是在谈论数据库层。取而代之的是,我们谈论的是域和数据映射器(OR/M,即实体框架(之间的边界。
博士
如果整个存储库需要某种投影,这意味着这些项目是域层期望的域对象,我发现这样的投影是在正确的位置实现的。
毕竟,正如我在上面的长文本中所说,我在基于 OR/M 的解决方案中根本没有看到数据/数据库层......
考虑单一责任原则并将其应用于您的图层。
"业务层"的责任,如果名称有任何含义的话,就是表达业务:它是规则,流程,逻辑,概念。如果你的业务层中有非技术人员无法查看和理解的东西,那么它可能不应该存在。
您向我们展示的代码的责任似乎是从您的持久性技术格式映射到您的业务层可以理解的类。
这种责任正是存储库应该封装的。所以代码在正确的位置。
如果你把它放在业务层,你就正在走向泥球架构。