直接使用LINQ生成的类？

Question

LINQ将从SQL文件生成一组类。这些应该直接使用还是应该包装在另一个类中，以便模型不依赖于实现？

Answer 1

你可以这样做。通常我会将Linq包装到SQL类中，但如果应用程序很小，则可以直接使用存储库方法。

如果应用程序较大，则可以添加业务层。

Answer 2

如果您确实需要从您的sql数据库的模型中进行抽象，那么Linq-To-Sql可能是错误的选择。当然，你可以使它工作（但这不是它的目的）。

如果您需要这种抽象级别，您将需要转向更“企业”的ORM，如Entity Framework。他们需要更多的配置，用于指定更复杂的映射，使您的对象模型和数据库模型彼此不相似，另一方面，如果这是过度杀伤，那么使用Ling to Sql。这很简单，而且很简单，只要你坚持使用简化的映射方法即可。

Answer 3

我认为它的罚款，直接在您的业务和表现层使用生成的模型类 - 不过，我肯定会封装的一些描述（GetOne()，Save()，Search()，Delete()等）的存储库模式中这些实体的数据访问。

这样做的主要原因是在将查询结果返回到调用层之前“断开”查询结果，以便客户端在返回的结果上使用LINQ时不会无意中直接对数据库执行查询。例如，在IQueryable<T>上调用ToList()将返回可以使用纯LINQ to Objects管理的序列的本地副本。

它还促进了更好的图层分离和更少的耦合，因为客户端将通过存储库上的接口方法进行交互，而不是直接使用LINQ to SQL来进行数据访问，所以如果您决定挑选LINQ to SQL来支持实体框架（不寒而栗），它更容易做重构。

我会做的一个例外是当LINQ to SQL对象需要跨越服务边界，即作为数据传输对象发送到WCF服务或从WCF服务发送。在这种情况下，我认为有一个支持序列化的独立轻量级对象模型是个好主意 - 不要直接通过线路将LINQ发送到SQL对象。