大型数据库的ORM

        数据库是否规范化是您需要了解并需要回答的问题！ 至于ORM：它实际上取决于数据的类型及其结构。 Linq-to-SQL是一个非常简单的ORM，它基本上只是将表1：1映射到域对象。只要您不需要其他任何东西，就可以了。 Linq-to-SQL不再被积极开发，因此这可能是一个缺点。而且，存储的过程支持有些限制。 实体框架（至少在.NET 4中）很棒，并且是Microsoft当前选择的ORM-它正在积极开发中，具有大量的支持和灵活性。它提供数据库优先，模型优先和代码优先的开发样式，它支持POCO对象和自跟踪实体，并且与存储的proc很好地集成在一起（您可以在每一个上为INSERT，UPDATE，DELETE定义存储的proc。实体（如果您愿意的话）。这将是我的第一选择。 NHibernate是一个出色的企业级ORM，已经建立并正在积极开发-肯定不是像Linq-to-SQL那样的“死胡同”。我在几年前就使用过它，虽然功能强大，但它比EF4更加难学（没有视觉设计师，需要更多的体力劳动和手工劳动）。如果您真的需要它的所有功能，并且愿意花必要的前期学习时间，那就太好了。 至于数据库：在研究过程中，绝对值得使用存储的proc，特别是如果您需要将某些数据库处理封装到一个不错的proc中以从代码中调用时，尤其如此。对于过多使用触发器和函数，我会非常谨慎和防御-它们应有其用，但不应过度使用，因为它们确实会带来一些问题（主要是性能问题和“可发现性”问题-许多开发人员不会考虑可能存在的触发器，并且不会理解正在发生的事情。     

@Xulfee，这是一个相当广泛的问题，很大程度上取决于您的项目的性质。您引用的方法会影响整个体系结构的许多方面。例如： 数据库是否已完全规范化？ 数据库规范化通常有助于解决概念模型的复杂性问题。当正确地规范化（注意，我没有说“完全”）时，您的模型应该相当简单，数据库的使用者（开发人员，您的BI团队，领域专家等）应该有一个好主意。数据库正在解决的业务问题。话虽这么说，规范化可能导致相当大的报告和分析问题。当针对一个大型的，标准化的数据库编写报表查询时，您可能会通过连接许多表而引入性能问题。输入雪花模式。所以，对您的问题：这取决于。您有什么报告要求？您平均需要支持多少笔交易？您的概念模型有多复杂？您是否可以将数据库分解为关联的较小模型，而不是一个较大的模型？ 哪个ORM（linq2sql，实体框架）适合该项目？ 同样，ORM是一种工具。您必须问自己，您要完成的具体工作是什么？我建议您尽早选择ORM（或首先使用ORM），因为它会影响从性能到开发团队凝聚力的所有方面。有很多很棒的选择： Linq到SQL NHibernate 实体框架 LLBLGen 上述每个框架在抽象您的持久层方面都做得非常出色。每个都有其优点和缺点-其中大多数归结于基础架构方面的问题：性能，配置，架构/语言兼容性，持久性模式，供应商支持。如果有选择的话，我会问自己，我的开发团队最喜欢哪种框架？哪一个支持我期望的系统活动级别？我愿意与哪个供应商“投入”？我已经看到使用相当小的ORM的相当成功的系统（即Stackoverflow使用Linq-To-Sql的修改版），以及由于相当复杂的ORM而相当大的系统会失败。 我应该使用存储过程，数据库函数，触发器等吗？ 这个问题围绕您的持久性存储及其使用方式（以及您想使自己的DBA生气的程度）围绕。使用sproc（存储过程）可使其dba在非常精细的级别上提供安全性。另外，如果您正在使用的orm生成动态sql，则您可能会受益于数据库缓存使用sproc生成的查询的功能。 DB功能可以是双面刀片。它们提供了为模型添加功能和智能的能力，同时又使您可以在性能方面取得相当大的成功（即，表值UDF \）。触发器有其自身的陷阱，应谨慎使用，但讨论可能会涉及很多。在这种情况下，对我来说最重要的是：您要支持数据库中的多少逻辑，安全性和性能有多重要？您是否有合格的dba（不仅仅是一个知道如何编写查询的开发人员，而是一个具有性能调优和数据建模能力的dba）？您的数据库有多大？您的数据有多复杂？在确定如何管理数据时，请考虑所有这些问题以及更多其他问题。 总之，您在问一些好问题。不要将基础架构需求与实施需求相混淆。确定一个堆栈并运行它，不要陷入实现细节中，直到无法成功完成项目为止。使用正确的抽象级别，您可能会发现尝试新技术和不同技术会更加容易，而不会冒着项目整体成功的风险。请记住：尝试和尝试新事物没有错，只是要准备好优雅地失败并进行测试，测试，测试！