我们即将开始在中型ASP.Net MVC 2网站上开发。对于典型的页面，我们抓取数据并将其丢弃在网页上，即在将数据发送到UI之前没有太多的数据预处理。
我们现在决定是否使用ORM，如果是，是哪一个。我们一直在关注EF2 AKA EF4（VS 2010中的ASP.Net实体框架）。
但是，我认为在这种情况下一个简单的解决方案可能只是使用数据表。原因是，一旦我们获取数据，我们不打算移动数据或处理它，所以我不确定将强类型对象作为DTO有多少价值。此外，这种方式我们完全避免映射，因此我认为简化代码并允许更快的开发。
我应该提到预算是这个项目的一个问题，以及执行的速度。我们在任何可能的地方都在努力实现简化，既可以缩小预算，又可以缩短计划，提高性能。
我们还没有完全决定这一点，但目前倾向于没有ORM。没有ORM方法我们会好吗，还是值得的ORM？
答案 0 :(得分：5)
ORM工具不是强制性的！
Jon的建议是明智的，但我认为使用DataTables并不理想。
如果您使用的是ORM工具，则对象模型比完整的OO域模型简单得多。此外，例如，Linq2Sql和Subsonic是直接使用的。在数据库更改时允许非常快速的代码更改。
你说你不会移动数据或处理它很多，但是在ORM对象而不是DataTables中，任何数量的处理都会容易得多。同样，如果应用程序发生变化并需要更多处理，DataTable解决方案将变得脆弱。
答案 1 :(得分：4)
如果你不打算进行全面的面向对象编程（并且我的意思是你应该对OOP有一个非常深刻的理解，而不仅仅是脱口而出的原则和设计模式名称的能力）那么不，它是不值得去做ORM。
ORM仅在您的组织完全投入面向对象的应用程序设计时才有用，因此存在具有对象关系模型映射的问题。如果你没有完全进入OO，那么ORM将成为你的组织认为不需要的某种令人讨厌的障碍。
如果您的团队/组织的编程风格始终倾向于将业务逻辑保留在DB中（例如，存储过程）或者在编写对象和方法时坚持使用或多或少的功能/过程/静态方法，请不要使用ORM和坚持ADO.NET。
答案 2 :(得分：1)
听起来好像你只需要显示数据而不做CRUD。
我发现在显示由各种表中的数据组成的列表时，ORM不是最好的方法。你最终只是加载大型对象图来获得这个必需的字段。
SQL语句在这方面要好得多。 我仍然会从DAL返回强类型对象的列表。因此，当DAL中的更改未反映在其他层中时，您更有可能获得编译时错误。
答案 3 :(得分：1)
如果您已经拥有了所需的存储过程，那么ORM可能没有那么多。如果没有，尽管我的经验是使用Linq to Entites比传统的存储过程/强类型数据集方法快得多，假设您对Linq查询感到满意。
如果您不担心映射到对象模型，那么Linq to SQL甚至更易于使用。您当然不需要使用完整的OO模型来获得生产力优势。
它不同意Malcolm关于必须返回图形的观点，如果ORM支持Linq你可以使用一个投影来返回一个只有你想要的数据的平面结果，并且附加的优点是查询通常比相应的SQL更简单因为你可以使用关系而不是加入。
在完成切换并熟悉该技术后，我可以想到这几乎没有理由不使用它，如果你真的需要，它们都支持回退到SQL存储过程。虽然会有一个学习曲线，但在这种情况下可能会让你感到不值得。
答案 4 :(得分：0)
我同意Joe R的建议 - 关于改变的速度＆amp;初始开发的速度，LINQ-to-SQL或亚音速也能让你快速上手。
如果您的应用程序真的很简单，并且它只是直接映射到表格的直接数据输出/数据，您是否考虑过查看ASP.net dynamic data？
我还指出Scott Guthrie对此有一个很好的article。
答案 5 :(得分：0)
这在很大程度上取决于你对ORM的熟悉程度。
我个人认为NHibernate是.NET世界中ORM的王者，它允许更快速的开发，因为一旦设置，您几乎可以忘记如何从数据库中获取数据。
然而，它有一个陡峭的学习曲线，特别是如果你尝试以非黑客的方式做事（你应该这样做），所以如果你的团队没有经验，时间紧迫那么可能不会削减它。
Linq2SQL太简单了。不了解Subsonic，但是如果你打算使用ORM，那么在快速开发和获得太强大和复杂的东西之间可能是一个很好的平衡。
但最终，作为一个团队，我认为你想要学习NHibernate，一旦你知道自己在做什么，就建立一个中小型项目并不费时，但是非常强大。