ORM vs SQL XML，非常简单的中间层答案

【问题标题】：ORM vs SQL XML, very simple middle-tierORM vs SQL XML，非常简单的中间层
【发布时间】：2010-06-18 08:30:47
【问题描述】：

我知道这是一个相当激烈的问题。但无论如何，我想听听 Stackoverflow 中的人的意见。鉴于 SQL Server 2005/2008 中对 XML 的支持非常好，而且无需担心数据库的独立性，为什么需要 Linq-to-SQL、Entity Framework、NHibernate 之类的东西，这些在高级用例中相当复杂和笨拙，如果通过使用 POCO、XmlSerializer 和处理 XML 的存储过程，是否可以实现不那么复杂的中间层？参考链接：http://weblogs.asp.net/jezell/archive/2007/04/13/who-needs-orm-i-ve-got-sql-2005.aspx

【问题讨论】：

标签： sql-server entity-framework orm

【解决方案1】：

“不太复杂的中间层”让我担心...... ORM 的重点是确保大部分复杂性与您的实际领域相关（无论是订单处理、提要阅读还是其他） .这种复杂性必须在某个地方。而最后你想要复杂性的地方是在数据库中 - 你最不可扩展的商品（你通常扩展数据库服务器up（这是昂贵的)，当您扩展应用程序服务器时out（便宜得多））。

可能会有使用文档数据库而不是关系数据库的情况，但 RDBMS 不会有任何进展。一般我建议：将您在数据库中的 xml 使用限制在合理的范围内。它可以是一个非常有效的工具 - 但要小心你没有创建一个内部平台。关系数据库（由任何供应商提供）在其工作中异常，具有复杂的索引、ACID、引用完整性等......利用了这种能力。

【讨论】：

谢谢你，马克。在我看来，对于 CRUD 应用程序来说，XML 确实是很有吸引力的选择。所有领域数据最终都会进入数据库，它们之间的复杂关系也是如此。那么，为什么不将并发管理等数据库密集型任务放在 db 级别，而不是依赖 ORM 的变更管理呢？
@synergetic - 好吧，并发不一定是数据库最密集的事情。许多系统是读取密集型的。在这里，乐观并发可能会显着减少成本，但仍然提供所有安全性。

【解决方案2】：

数据库中的 XmlSerialization 和 XML 列可能很难使用，但我相信你可以让它工作。您仍然必须克服标准 ORM 挑战，例如循环引用。 SQL 查询对于 XML 数据库列可能会很尴尬。

我认为在高级用例中复杂的不是 ORM，而是在高级用例中复杂的对象关系不匹配。我看不出 XML 和存储产品如何真正以更好的方式解决这些高级用例。

XML 在本质上不是关系型或面向对象的，您正在添加额外的不匹配。

【讨论】：

谢谢迈克尔。虽然可以有 XML 列，但我在这里谈论的是普通的 int、varchar 等列。使用“FOR XML”语句，我可以轻松地在存储过程中创建 xml 并发送给客户端。通过 ADO.NET 命令，我还可以轻松地将 xml 发送到存储过程。一旦进入存储过程，无论我想对即将到来的 xml 做什么，我都拥有完全的灵活性，比如构建我自己的并发处理逻辑。但如果你使用 ORM，我觉得你可能不得不处理大量生成/臃肿的代码，最终可能无法完成你想要的。
@synergetic：听起来您正在将 XML 添加到对象和关系表中，实际上您现在遇到了另一个阻抗不匹配。通常，ORM 不需要“生成的”代码，您可能希望花更多的时间在高质量的 ORM 上，然后再轻易放弃它们。大多数开发人员都尽量避免在代码和存储过程之间拆分业务逻辑。
谢谢迈克尔。你用什么ORM？能给我推荐一个吗？
@synergetic: stackoverflow.com/questions/1377236/…