Question

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

我决定使用LINQ to SQL作为数据访问层。我应该为Use for Business层和Presentation层编写单独的类，或者我使用LINQ to SQL自动生成的实体类。

Answer 1

我使用Entity Framework Code First，但以下概念是相同的（用于非平凡的项目）：

我总是将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类。

Answer 2

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

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

非常适合我们。

由Linq生成的单独的业务类或实体类到SQL

2 个答案: