我没有在项目中使用 LINQ to SQL，我只是通过了一个使用 LINQ 开发数据访问逻辑的动手实验，其中一项任务是创建实体转换器类以在 linq 实体和业务实体之间进行转换。
我对此有点困惑，因为我认为我们使用 LINQ to SQL 的原因是它可以为我们自动生成 LINQ 实体，我们可以立即查询/更新/插入/删除实体。如果我们不必定义我们自己的自定义实体并为我们的实体和 LINQ 实体之间的映射烦恼，那就太好了。但是由于实验室定义了业务实体，我知道我错了。
谁能告诉我在什么情况下我们应该定义业务实体而不是立即使用实体 LINQ to SQL？在这种情况下对 ADO.Net 使用 LINQ to SQL 有什么好处？期待您的回复，在此先感谢您！
【问题讨论】：
标签： .net linq-to-sql entity
使用 LINQ 实体将您绑定到数据持久性。对于许多应用程序来说，这没什么大不了的。但对其他人来说，这是一个非常糟糕的设计。
例如，如果您的应用程序公开了一个外部 API 供客户使用，那么您不希望将持久性实体公开给您的客户。否则，如果您需要更改您的数据模型（需求更改、在更大范围内调整性能等），那么您也将更改您公开的 API。
对于许多大型和更复杂的项目，您希望在业务对象和数据持久性之间保持清晰的分离。如果程序员和 DBA 在不同的团队并做不同的事情，则尤其如此。他们应该在设计上一起工作，但是编程逻辑和数据库持久性是不同的技术，具有不同的进步和局限性。它们之间的映射是它们将如何进行通信，但不应受制于另一个的限制。
正如其他人所说，对于许多较小的项目来说，这没什么大不了的。如果您的应用程序只是数据上的表单，并且数据相对简单，并且直接关系不会改变，那么使用 LINQ 类就可以了。
【讨论】：
LINQ 实体与您的数据库列完全匹配。如果您的业务实体也这样做，那很好，您可以直接使用 LINQ 实体（我通常这样做）。
如果您的业务规则需要更复杂的业务实体，则需要将它们映射到 Linq 实体。
【讨论】：
您提出了一个很好的问题，这就是为什么很多人（包括我自己）觉得在 L2S（或其他 ORM）实体之上构建一层业务对象是浪费时间。如果您需要完成这些步骤才能完成实验室（用于学校作业或类似的事情），那么请这样做，但我不建议将其用于实际环境。
【讨论】：
这取决于您的数据。我曾使用过一些疯狂的有机进化的数据库，其中有许多未使用的列被保留用于从其他应用程序进行历史查找（该死的 SOX 合规性> =（）和许多其他问题。
我们创建了业务对象映射来隐藏所有这些历史缺陷，并为代码的其他区域呈现干净的外观。
【讨论】：