对于新的小型应用程序来说，实体框架值得迁移吗？
对于新的小型应用程序来说，实体框架值得迁移吗？大约 10 个表格和一个 WinForms 应用程序。
即替代方案是 DataTables/DataRows 或 Linq-to-SQL
Is Entity Framework worth moving to for a new small app? About 10 tables and a WinForms app.
ie the alternative being DataTables/DataRows or Linq-to-SQL
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不同意那些说 LINQ to SQL 更适合小型项目的观点，这是基于在小型项目中使用 LINQ to SQL 和实体框架的实际经验。我很难克服 LINQ to SQL 极其薄弱的架构更新场景（扔掉旧模型，重新生成新模型，然后重新应用自定义）。大多数情况下，您可以使用这两种工具完成您需要做的事情，但是如果您的数据库模式发生变化或发展，您将花费太多时间摆弄 L2S 设计器。
避免使用实体框架的最好理由是您不理解它。我并不是在这儿胡言乱语；如果您确实了解 L2S 但不了解 EF，那么请务必使用 L2S；你可能会更有效率。但是，如果您了解这两种工具，那么 EF 几乎可以完成 L2S 可以做的所有事情，甚至更多（简单的模型更新、模型优先、代码优先模型、可定制的代码生成、RIA 服务等） 。
I'm going to disagree with those who say that LINQ to SQL is preferable for a small project, based on real-world experience using both LINQ to SQL and the Entity Framework for small projects. I have a really hard time getting over LINQ to SQL's incredibly weak schema update scenario (throw away your old model, re-generate a new one, and re-apply your customizations). You can do what you need to do with both tools, for the most part, but if your DB schema will ever change or evolve you'll spend way too much time fiddling with the L2S designer.
The best reason to avoid the Entity Framework is if you don't understand it. I'm not being flip here; if you do understand L2S and you don't understand the EF, then by all means use L2S; you will probably be more productive. But if you understand both tools, the EF can do nearly everything that L2S can do and much, much more (easy model updates, model-first, code-first models, customizable codegen, RIA services, etc., etc...).
实体框架是一个很棒的产品 - 但它显然是为更高级、更复杂的情况而设计的，在这些情况下，您需要能够拥有一个与底层存储模型不同或可以不同的域对象模型。如果您需要的话 - 很好 - 但对于大多数较小的应用程序来说，这完全是矫枉过正，只会增加额外的性能杀手层。
对于小型应用程序，请使用 Linq-to-SQL - 或查看 Subsonic< /a>.它们都在表格顶部提供了非常薄且非常简单的层，并且它们非常适合较小的应用程序。
DataTable 已经是 90 年代的了……远离它们，它们很混乱，很难使用，使用起来不愉快且效率低下。
Entity Framework is a great product - but it's clearly designed for more advanced, more complex cases, where you need to be able to have a domain object model that is or can be different from your underlying storage model. If you need that - great - but for most smaller apps, this is total overkill and only adds additional layers of performance killers.
For a small app, go with Linq-to-SQL - or have a look at Subsonic. Those both offer quite thin and very simple layers on top of your tables, and they work great for smaller apps.
DataTables are so 1990's .... stay away, they're messy, they're hard to use, they're not pleasant and not efficient to work with.
对于一个小项目，我可能会选择 LINQ to SQL。
I would probably go for LINQ to SQL for a small project.
远离数据表。 IMO，LINQ to SQL 应该足够了。
Stay away from datatables. LINQ to SQL should be enough, IMO.