我有非常小的asp.net MVC 2应用程序来维护/扩展。目前它使用手写存储过程+应用程序代码进行数据访问。基本上它的作用是它加载数据并将其包装到POCO。
目前的实施很难维护。特别是当我必须添加新属性时 - 更不用说为CRUD添加新类/表了。应用程序具有单独的缓存，这也很难维护 - 并且它导致了一些缺陷。我也想摆脱它。
我开始考虑切换到一些ORM工具，如NHibernate或Entity Framework。
我在ORM或数据访问方面的经验非常有限。在这种情况下，最佳做法是什么？在跳转到NHibernate / Entity之前我应该考虑什么？那些缺点呢？
答案 0 :(得分：3)
“最佳实践”是我最不喜欢的词之一 - 它通常被用来赋予意见更多的重要性，而不是真正值得...
说完了......
首先，选择您的数据库访问策略; ORM是当前事实上的行业标准，您已经确定了领跑者;请参阅this主题进行比较。
不同的数据库访问方法会牺牲不同的东西。您的应用当前使用的那个提供了对查询及其映射到您的域的方式的大量详细控制 - 但是以大量手动编码为代价。它可能提供最佳性能和最大灵活性;有些人认为这是最容易维持的，因为开发人员没有“神奇”来解决问题。
ORM解决方案为更短的开发交易性能和控制，并且（有些人认为）更容易维护。有一个学习曲线，“魔术”的中间层可能使一些问题难以识别 - ORM的经典反模式是“将整个数据库加载到内存中”，但性能问题调试也很棘手。另一方面，您减少了总代码量，并使构建简单的CRUD操作变得更容易。具有ORM经验的开发人员会发现维护起来更容易;不熟悉ORM的开发人员必须学习该框架。
总的来说，我认为对于没有极端性能要求的应用程序，业界正在转向ORM;它正在成为主流，我们这些天采访的大多数开发人员都有ORM的经验。然而，学习曲线可能非常陡峭，并且有一个明确的鸡肉和鸡蛋 - 你选择ORM而没有经验吗？ FWIW，我认为Steven Lacy的答案就是那里的钱......
你提出的建议基本上就是重构。我建议按以下方式进行处理：
我至少会像在重构中那样努力创建测试 - 在你替换当前的实现之前，我会拒绝添加新功能的冲动。
确保您的测试包括性能和可伸缩性测试。
答案 1 :(得分：3)
我已经使用了NHibernate和Entity Framework。
在工作中我们使用了Entity Framework，因为它更容易说服其他人使用它而不是开源应用程序。
我遇到的绝大多数开发人员都使用NHibernate，但两者都有其缺点，他们在访问数据时需要做的工作量较少，但也限制了你。
目前在EF中我遇到了一个问题，我无法在SQL服务器上使用全文搜索，因为EF不支持。我可以通过上下文直接查询，但我更倾向于使用表值函数，这应该很容易用Linq2实现，但由于某种原因，EF团队还没有完成。
确保您遵循工作单元模式，您的会话在需要时创建并在Web请求结束时销毁。它们都设计为在这些条件下运行良好，像在应用程序范围中保存上下文/会话一样，您将遇到问题。
构建您的应用程序，就好像您计划将来切换ORM一样，因为您的第一个评论者表示您可能不得不这样做。 您的域对象应该是POCO，它们应该没有持久性知识
购买EntityFramework教授或NHibernate教授（它将帮助您优化查询）
预计这会花费相当多的时间来适应您选择的任何框架。购买一本书并开始阅读您所选择的技术，在它们成为阻截者之前尽早提出有关stackoverflow的问题。
使用Code first EF或Fluent Nhibernate，映射在运行时中断，在编译时流畅中断。
使用Linq2Entities或Linq2Nhibenate，强类型查询可以在80％的时间内使生活更轻松。
没有像EDMX这样的巨型xml文件，这对于版本控制来说非常困难。 谨防代码生成，它有所帮助......但在许多情况下它也很危险。
我强烈建议您在更改现有代码之前尝试从示例项目开始。小型项目可以让您改变主意。