我正在尝试理解代码生成工具/ ORM工具的选择，并发现哪种解决方案最能满足我的要求和存在的限制。
我正在创建一个用于新项目的基础解决方案。它由ASP.NET MVC 3.0，业务逻辑层和数据访问层组成。数据访问层现在需要针对Oracle，然后在db迁移完成后切换到SQL。
从DTO立场映射到解决方案中的自定义类型，ORM /代码生成工具将用于创建我需要的代码，但只能访问Oracle和SQL中的存储过程。
意思是，我需要生成自定义对象，这些自定义对象是作为参数的存储过程并被推送到存储过程，我不需要自己生成sprocs，它们已经存在。我正在寻找sproc需要的表示，并将其生成回到DTO中。在某些情况下，我可以反对意见并生成DTO。我假设大多数工具已经这样做了。但是在90％的情况下，我无法直接访问任何表或视图，只能访问存储过程。
这有意义吗？
答案 0 :(得分：0)
ORM最适合将对象映射到表（和/或视图），而不是将对象映射到sprocs。
很少有工具可以针对sproc可能生成的任何输出执行自动代码生成，具体取决于sproc的复杂性。代码生成输入到sproc的更直接，因为它通常定义明确且清晰。
我想说如果你遇到了垃圾邮件，那么使用第三方代码来减少开发和维护时间的选择将受到严重限制。
我相信LinqToSql或EntityFramework（或两者兼而有之？）能够在SQL Server方面有一些神奇的功能，试图主要自动找出sproc可能返回的内容。我不认为它一直有效，它只是复杂的猜测工作，我严重怀疑它是否适用于Oracle。我甚至没有发现任何软件方面的东西，甚至试图弄清楚sproc可能会返回什么。
sproc可以返回多个不同的记录集，这些记录集可以由sproc动态构建，具体取决于数据库中的输入和数据。自动预测sproc输出的技术解决方案似乎需要以下内容：
这将为您提供任何给定有效输入的静态可能输出集。数据库中的数据发生微小变化可能会使一切无效。
如果我没记错的话，微软所做的就像调用sproc为所有输入参数传递NULL并假设输出始终是从数据库返回的第一个记录集。这显然是问题的一个不完整的解决方案，但在简单的情况下，它似乎很神奇，因为它可以在某些时候很好地工作。