实体框架对于小型企业应用程序来说是不是太过了?

本文关键字：是不是过了应用程序框架于小型企业实体 | 更新日期: 2023-09-27 18:16:25

我正在为特定行业的小型企业创建c#/SqlServer应用程序。它是一个重写的VB6应用程序，有近100个数据库表。它不像某些应用程序那样位于由应用程序和数据库组成的大型企业结构中。它是独立的，只会有大约1-3个开发人员在工作。

对于这样的应用程序，实体框架会是多余的吗?我正在寻找至少一个微型ORM来简化应用程序的数据访问部分，但是一个完整的ORM是一个过度的?

编辑:我本以为orm很大程度上适合更大的开发环境。

EF是否"过度"完全取决于上下文;的确，你提到了"相当沉重的稍后"，但在许多方面，这对于"小型企业应用"来说是无关紧要的，因为你不会让它承受巨大的负载。那么，您甚至可以争辩说，使用ORM做除了之外的任何事情都是多余的(因为它增加了开发工作)。

你还提到了微orm;事实上，它们将减少大量的原始ADO。NET代码(您可以在注释中挑出)。简单。数据提供了一个很好的抽象层，也避免了编写TSQL的需要——这可能是一个不错的起点，但是有了100个表，我可以看到EF/L2S等的许多吸引人的方面(特别是对于所有对象的存根)。但是，EF 本身有很多…"功能"(意思是:脚趾的地方)，这意味着你仍然需要学习英孚的一些工作方式。不可避免的是，所有的抽象都在某种程度上做到了这一点——所以这是一个权衡这种成本与手工操作成本的案例。

绝对不过分。

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

仅当

时使用SQL

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

只有当您这样认为时，ORM才是多余的。对于100个表，它看起来是合理的。

您可能更喜欢一些微型ORM(如SimpleData或Massive)，但这取决于您:当EF强制使用强类型时，微型ORM可能涉及与DB的过于松散的耦合。