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