我很惭愧地说出来，但我必须这样做。我没有和ORM合作过。我真的在考虑NHibernate，因为它似乎是.Net最成熟的产品（如果我错了请纠正我）。现在，我们有一个庞大的电子商务/预订系统，以SqlServer作为主要集成点，在sprocs中包含了大量的业务逻辑。现在 - 显然 - 这个架构是我们想要摆脱的东西，而且我们已经一段时间地这样做了。所以，我真正的问题是，开始使用NHibernate获取新功能并且不返回并映射所有遗留内容是多么可行？是否支持这种逐步引入和ORM，如果是这样，你会推荐吗？
答案 0 :(得分：3)
如果您使用的是旧数据库，您会发现ORM工具难以使用，配置，维护和优化。当我们使用NHibernate将我们的域模型映射到现有数据库时，我们遇到了许多问题。其中一些是：
模型对象很难映射到现有表（我们有超过100个表），NHibernate的一些要求非常突兀，因为每个表都必须有一个ID字段才能映射到一个Domain对象。此外，很难掌握和使用多种关系。
维持大量的 映射映射到的XML 遗留数据库成为一个全职 为开发人员工作并且相当 具有挑战性，特别是在一个团队中 10多位开发人员。
由于数据模型和对象模型并不总是与业务相匹配并且需要不断调整，因此随着复杂性的增加，我们的查询性能下降。必须编写大量的数据聚合代码。例如，如果我们需要显示一个连接多个表的网格，我们以前必须加载多个Domain对象，将它们放在一起并在一个网格中显示它们。该代码很难维护和调试。
此外，有时我们必须运行匿名查询，即我们只需要某些对象的一些属性，而不是整个对象。这真的很难编写，维护甚至实现，并且违反了ORM范例，但我们别无选择，只能这样做。
我们遇到的另一个问题是数据库不断变化，因为DBA会重构表格并且总是会破坏我们的Domain对象。这是一个让模型和表格保持同步并确保应用程序仍然有效的练习。
长话短说...我们了解到，如果有一种方法可以将业务所需的SQL直接映射到我们的UI模型或域对象而不必担心配置，那么这将是一个更好的解决方案。
经历了这次经历后，我们开发了Orasis Mapping Studio。它是一种映射工具，专门用于处理遗留数据库以及现有的.NET模型/域对象。它采用SQL查询并允许您通过以图形方式显示Query和Object的元数据并使用拖放操作在Object属性和Query列之间创建映射来将它们映射到现有的.NET对象。该工具会自动生成执行映射以读取对象所需的所有ADO.NET代码。然后，您可以在DAL层中使用生成的代码，或使用生成的Assembly来检索和保留数据。
您可以在此处尝试：Orasis Mapping Studio。它是我们认为开发人员真正需要的工具，特别是对于使用旧数据库以及性能是关键要求的工具。它由开发人员为开发人员编写，因此它处理一些复杂的细节，如Obejct继承，嵌套对象，数据类型转换等。祝你好运！
答案 1 :(得分：2)
这将取决于您当前数据库的“NHibernate友好”。 NHibernate喜欢单列主键（如果它们都更好地命名为“id”）。据我所知，大多数ORM并不是非常友好的。您是否考虑过如何定义传输对象以从数据库中来回传输数据？
BT，没有什么可以感到羞耻的。 ORM是一个很好的东西，但你正试图找到最好的方法。答案 2 :(得分：1)
我没有亲自完成此操作，但您可以将映射文件中的存储过程复制粘贴到命名查询中，稍后逐个删除它们。
如果您对ORM没有任何经验，可能很难在大型遗留项目中开始学习它，因为您必须发现在绿地项目中不会使用的ORM的所有非标准功能，或每年只使用一次。 NHibernate有很多选项可以支持遗留数据库。
当您准备好跨越学习曲线并勇于开始使用新技术时，您可以从NHibernate开始，但如果您想逐步学习新技术，我会等待NHibernate，直到您开始新的绿地项目。
答案 3 :(得分：1)
任何体面的ORM工具都应该支持渐进式集成。这里的技巧是在DAO级别（数据访问对象层）清晰分离。如果您可以通过定义良好的API隐藏数据访问怪癖，那么无论您是否使用ORM都无关紧要。
话虽如此，ORM介绍的复杂性直接与表模型的复杂性有关。您可以为同一个表创建许多不同的映射，只需确保事先进行一些试验，以便了解ORM解决方案的怪癖，例如具有对象缓存，后写查询，代理访问等。 ORM解决方案的真正好处是使用对象而不是虚拟POJO类。这使得对业务的更改比使用sprocs或扁平对象更容易。
作为旁注，我参与了一个项目，我们将sprocs中的整个应用程序迁移到java。虽然我们没有使用sproc，但真正的痛苦是sprocs架构没有很好地定义，许多sprocs调用其他sprocs使得很难一次只迁移一些sprocs。
答案 4 :(得分：1)
NHibernate中没有任何内容可以限制你这样做。在某些时候，您可能希望将遗留代码转换为也使用NHibernate，因为在您可以浏览所有对象之间的关系之前，您将看不到ORM的全部好处。
这方面的最大挑战可能是让您的遗留表结构符合NHibernate每类方法的单表。有办法解决这个问题，但这可能很棘手。不过，我认为这是值得的。
答案 5 :(得分：1)
您之前提到过您正在逐渐远离当前的架构，但是您需要坚持使用遗留数据库设计（例如，DBA严格负责设计和维护它）或者您当前的数据库设计是否已经过重构（需要考虑）对于O / R映射器）？
如果很难摆脱当前的遗留设计，你可以考虑使用普通的旧T-SQL查询，而不是使用普通的旧T-SQL查询来查找像iBATIS SqlMap到O / R映射实体到其旧数据库的其他内容。用于映射数据的不太灵活的Hibernate样式XML /属性。
根据您希望如何接近设计，您可以通过使用自己的抽象iBATIS SqlMap工厂或{{3}来透明地并排使用DAO和NHibernate （基本上就是这样，并且仍然与NHibernate兼容。）
答案 6 :(得分：1)
我同意艾哈迈德的说法，我过去曾遇到过类似的问题。我遇到的大部分麻烦都不是来自技术本身，而是来自开发人员的采用，改用NHibernate意味着改变工作习惯，至少可以说，这并不总是那么容易。
如果您是ORM的新手，最好用它来开始一个全新的项目而不是尝试转换旧项目。
我将遗留项目转换为ORM的建议是尝试使用某种生成工具，如LLBGen或.netTiers甚至Linq2SQL。这样你就可以在没有NHibernate强加的创伤性重写的情况下使用ORM更加舒适。
答案 7 :(得分：0)
为什么存储过程“显然”不好？存储过程中的业务逻辑是否会导致痛苦？
Microsoft似乎有许多可用的持久性技术（例如，LINQ）。我不知道如何评估它们与NHibernate相比，但除非你有很好的对象要映射，否则我不推荐使用ORM。