Linq To SQL 不可扩展是什么意思？
我曾经听一些开发人员说过 L2S 不可扩展。 我不确定我是否完全理解这意味着什么。 我想这与你的应用程序中的层有关（前提是你的 应用程序是分层的）。 有人可以解释一下这个问题吗？
谢谢， 阿维
I've once heard from some developers that L2S is not scalable.
I'm not sure that I fully understand what that means.
I guess that it has something to do with the layers in your app (provided your
app is a layered one).
Can someone please shed some light on this subject?
Thanks,
Avi
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这更多的是一种功能的可扩展性。如果您查看 LINQ 生成的域对象，您会注意到很多膨胀，如果您要迁移到另一个持久性框架（例如 NHibernate），这可能变得不必要。一种选择是推出您自己的更抽象的域层，并将生成的域映射到抽象域。保持域层“无膨胀”允许您在不同的持久性框架中重用它。 L2S 不太擅长。
其他的东西可能包括性能，但我认为这在以后的版本中得到了改进？
This is more of a functional scalability. If you look at your LINQ generated domain objects you'll notice a lot of bloat, which may become unnecessary if you were to move to another persistence framework such as NHibernate. One options is to roll out your own domain layer which is more abstract and map your generated domain to the abstract one. Keeping your domain layer 'bloat-free' allows you to reuse it with different persistence frameworks. L2S isn't very good at it.
Other things may include performance, but i thought this was improved in later versions?
我认为它的扩展性相当好，考虑到 Stack Overflow 使用它而且它不是一个小网站。
I think it scales reasonably well, taking in account that Stack Overflow uses it and it is not a small site.
即使您的集合很小，代码生成器生成的 SQL 也永远不会像手工编码的 SQL 那样优化，特别是如果获得良好的执行计划高度依赖于选择正确的索引。
假设您手动编码这些情况并使用 SP，在数据非常大的情况下，您将需要很多技巧来有效使用内存，无论您的数据库引擎是否可以帮助您。
但任何抽象都有其局限性。
Even if your collections are small, the SQL generated by a code generator is never going to be as optimized as hand-coded SQL, particularly if getting a good execution plan is highly dependent on picking the right indexes.
Assuming you hand-code these cases and use SPs, in cases where data is very large, you are going to need a lot of tricks to have efficient memory usage regardless of whether your database engine can help you or not.
But every abstraction has limits.