【发布时间】：2010-12-05 03:52:27
【问题描述】：
我曾经从一些开发人员那里听说 L2S 不可扩展。 我不确定我是否完全理解这意味着什么。 我想这与您应用程序中的图层有关（前提是您的 应用程序是分层的）。 有人可以解释一下这个问题吗？
谢谢， 视频
【问题讨论】：
【发布时间】：2010-12-05 03:52:27
【问题描述】：
考虑到Stack Overflow uses it 并且它不是一个小站点，我认为它的扩展性相当好。
【讨论】：
-
确实很有趣......但我猜他们可能已经找到了一些方法来克服它的局限性。
即使您的集合很小，代码生成器生成的 SQL 也永远不会像手工编写的 SQL 那样优化，尤其是在获得良好的执行计划高度依赖于选择正确的索引的情况下。
假设您手动编码这些情况并使用 SP，在数据非常大的情况下，无论您的数据库引擎是否可以帮助您，您都需要很多技巧来有效地使用内存。
但每个抽象都有限制。
【讨论】：
这更多的是功能可扩展性。如果您查看 LINQ 生成的域对象，您会注意到很多膨胀，如果您要迁移到另一个持久性框架（如 NHibernate），这可能变得不必要。一种选择是推出您自己的更抽象的领域层，并将您生成的领域映射到抽象领域。保持你的领域层“无膨胀”允许你在不同的持久性框架中重用它。 L2S 不是很擅长。 其他方面可能包括性能，但我认为这在以后的版本中有所改进？
【讨论】：
-
感谢您的及时回复。因此，如果我理解正确，L2S 本质上所做的是将您的域层链接到数据访问层，对吗？好吧，这听起来确实很糟糕，但这是可扩展性问题还是维护问题？我还不太清楚的另一件事是，您说有两个领域层，一个是由开发人员编写的，一个是生成的。我以前从未听说过两个域层。生成的域是由代码生成器创建的吗？然后映射到其他领域层？我还是不明白这个概念。非常感谢
-
这是一种功能可扩展性，如果有的话。 L2S 有一个实体生成器，它根据您的数据库模式创建域/实体层。您将要从中获得的领域模型与 L2S 紧密耦合。如果您希望以后能够移植到不同的持久性框架，您可能对创建抽象域模型感兴趣。但是，每次要检索或持久化数据时，都必须将 L2S 实体映射到抽象域实体（并返回），这是额外的开销。如果您的应用程序是可扩展的，您可以想象这里的痛苦。
-
对于大多数项目来说，这不是问题。不是每个人都这样设计。我只是一个纯粹主义者:)