分离由 Linq to SQL 生成的业务类或实体类

Question

我必须启动一个项目，其中支持的数据库是 SQL Server，并且我正在使用 .Net framework 3.5。

我决定使用 LINQ to SQL 作为数据访问层。我应该为业务层和表示层编写单独的类，还是使用 LINQ to SQL 自动生成的实体类。

Answer 1

我首先使用实体​​框架代码，但以下概念是相同的（对于非平凡项目）：

我总是将我的 DAL 类排除在我的实际业务层之外。这样可以减少数据库更改对您的应用程序的影响。除了我的 DAL 项目，我从不在任何地方使用 DAL 类。

我目前的项目使用 DDD，任何布局都类似于以下（大量简化）：

MainApp                    
MainApp.Domain             
   |...IRepositories
   |...AggregrateX
   |...AggregrateY
MainApp.Dal            
   |...Models
   |...Repositories 

• MainApp - 可以看到域，但看不到 DAL
• MainApp.Dal - 可以看到域，但看不到 主应用

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 类。

Answer 2

我可以告诉你我们做了什么。我们正在将 L2S 用于我们的下一代制造应用程序。我们是一家价值 2.5B 美元的全球太阳能制造公司。我们有两组实体。我们有我们在“后端”中严格使用的 L2S 实体。然后，我们有一组更轻量级的应用程序/域实体，它们在我们的客户端应用程序中使用并来回传递到我们的后端。

在许多情况下，我们将使用对域实体建模的视图，然后将视图作为只读表带入我们的 L2S 模型。这使我们能够拥有“域”实体，并且我们能够使用 L2S 来查询相应的视图以补充这些实体。

对我们来说效果很好。