Question

我正在对我的同事编写的以下代码进行代码审查，根据我的经验，投影和格式化活动类型不应该在DB层中完成，而应该在业务层中进行。但他并不相信。此DB层用于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()
                }
            );
        }
    }

更新：

CustomerDetails是db实体，它通过存储过程映射字段返回。我们正在使用存储库在ORM（EF）上放置一个抽象层，这样如果我们需要更改我们的ORM框架，它就不应该影响依赖层。

我认为，从存储库我们应该返回行数据，并且应该在服务层中完成相同数据的不同表示。

Answer 1

我会说 where 放置这种代码可能是一个设计决定，取决于实际情况。

此外，在使用OR / M框架时，我怀疑是否会有数据库层，因为任何OR / M都试图成为数据层本身，并且它们倾向于提供< em> Repository Pattern 类似于查询和编写持久对象的接口。也就是说，由于存储库是一个类似于集合的接口，它将底层数据格式转换为域对象（实体），所以看起来就像你所谓的层一样，它们将是仍然是域/业务层，或者可能是服务层 - 谁知道 - 。

此外，您的代码似乎是一个存储库（！），这意味着我们不是在谈论数据库层。而不是那样，我们谈论的是域和数据映射器之间的边界（OR / M，即实体框架）。

TL; DR

如果整个存储库需要某种投影，这意味着这些项目是域层所期望的域对象，我发现这些投影是在正确的位置实现的。

毕竟，正如我在上面的长篇文章中所说，我根本没有在基于OR / M的解决方案中看到数据/数据库层...

Answer 2

考虑单一责任原则并将其应用于您的图层。

“商业层”的责任，如果名称意味着什么，则表达商业：它的规则，流程，逻辑，概念。如果你的业务层中有你的非技术人员无法查看和理解的东西，那么它可能不应该存在。

您向我们展示的代码的责任似乎是从您的持久性技术格式映射到您的业务层可以理解的类。

这个责任正是存储库应该封装的内容。所以代码在正确的位置。

如果你把它放在业务层，你就会转向Ball of Mud架构。

我们是否应该在数据库层中进行投影和格式化活动

2 个答案:

TL; DR