实体框架会对小型企业应用程序造成过大的影响吗？

Question

我正在针对特定行业的小型企业中创建C＃/ SqlServer应用程序。它是一个VB6应用程序的重写，它有近100个数据库表。它不像某些应用程序那样位于更大的应用程序和数据库的企业结构中。它是独立的，只有1-3个开发人员可以使用它。

实体框架会对这样的应用程序造成过大的影响吗？我正在寻找至少一个微型ORM来简化应用程序的数据访问部分，但是一个完整的ORM是一种过度杀伤？

编辑：我认为ORM很大程度上适合更大的开发环境。

Answer 1

EF是否“过度杀伤”完全取决于上下文;事实上，你提到“后来相当沉重”，但在许多方面，对于“小型企业应用程序”来说，无关紧要，因为你永远不会让它承受巨大的负担。你甚至可以争辩说，使用ORM 做任何事情都是过度的（因为它增加了开发工作量）。

你还提到了微观ORM;实际上，它们会减少大量原始ADO.NET代码（您在评论中单独列出）。 Simple.Data提供了一个很好的抽象层，也不需要编写TSQL - 可能不是一个糟糕的起点，但有100个表，我可以看到EF / L2S /等很多有吸引力的方面（特别是对于存根）出你所有的对象）。但是，EF确实本身有足够的......“功能”（意思是：存放脚趾的地方），这意味着你仍然需要学习一些EF想要的工作方式。 Invariably, all abstractions do this to some extent - 因此需要权衡此费用与手动执行更多操作的费用。

Answer 2

肯定不是矫枉过正。

在我的工作场所，我们使用EF4.1或我们自己的ORM。它确实加快了开发速度，避免了编写粘合代码以将行映射到实例。

我们仅在

时使用SQL

• 性能胜过代码可读性/维护性
• 我们有ORM无法处理的查询

Answer 3

只有当你有这样的感觉时，ORM才会过度。有一百张桌子，看起来很合理。

您可能更喜欢一些微型ORM（例如SimpleData或Massive），但这取决于您：当EF强制进行强类型操作时，微观问题可能会导致您的数据库过于混乱。