LINQ实体与LINQ to SQL中的自定义实体

Question

我没有在项目中使用LINQ to SQL，我只是通过LINQ开发数据访问逻辑的实践实验室，其中一项任务是创建实体转换器类以在linq实体和​​业务实体之间进行转换。

我对此有点困惑，因为我认为我们使用LINQ to SQL的原因是它可以为我们自动生成LINQ实体，我们可以立即查询/更新/插入/删除实体。如果我们不必定义我们自己的自定义实体并且不必理解我们的实体和LINQ实体之间的映射，那将是很好的。但由于实验室定义了商业实体，我知道我错了。

有人能告诉我在哪种情况下我们应该定义业务实体而不是立即使用entite LINQ to SQL？在这种情况下，对ADO.Net使用LINQ to SQL有什么好处？我期待着你的回答，非常感谢！

Answer 1

使用LINQ实体会将您绑定到数据持久性。对于许多应用程序，这没什么大不了的。但对于其他人来说，这是一个非常糟糕的设计。

例如，如果您的应用程序公开了供客户使用的外部API，那么您不希望将持久性实体公开给客户。否则，如果您需要更改数据模型（需求更改，调整更大规模的性能等），那么您还将更改公开的API。

对于许多大型和更复杂的项目，您希望在业务对象和数据持久性之间保持清晰的分离。如果程序员和DBA在不同的团队中并且执行非常不同的事情，则尤其如此。他们应该共同设计，但编程逻辑和数据库持久性是不同的技术，具有不同的进步和局限。它们之间的映射是它们如何通信，但不应受另一方的限制。

正如其他人所说，对于许多小型项目而言，这并不是什么大问题。如果你的应用程序只是数据上的表单，并且数据相对简单，并且直接关系不会改变，那么LINQ类就可以使用了。

Answer 2

LINQ实体正好填补了您的数据库列。如果您的业务实体也这样做，那么没关系，您可以直接使用LINQ实体（这是我通常所做的）。

如果业务规则需要更复杂的业务实体，则需要将它们映射到Linq实体。

Answer 3

你问一个很好的问题，这就是为什么很多人（包括我自己）觉得在L2S（或其他ORM）实体之上构建一层业务对象是浪费时间的原因。如果您需要完成这些步骤以完成实验（对于学校作业或类似的东西），那么这样做，但我不建议将其用于实际环境。

Answer 4

这取决于您的数据。我曾与一些疯狂的有机发展数据库合作，其中有许多未使用的列保留用于从其他应用程序进行历史查找（该死的SOX合规性＆gt; =（）和许多其他问题。

我们创建了业务对象映射来隐藏所有这些历史瑕疵，并为代码的其他区域提供干净的外观。