新应用程序的DataLayer : MyGeneration和/或实体-框架

Question

该平台是ASP.Net 3.5sp1，带有Oracle。我们考虑了MyGeneration和实体框架在DataLayer中的时间和方便性(以及业务层中的一些基类)。

我的问题是：

1. 与MyGeneration相比，使用实体框架有什么利弊？
2. 对于使用MyGeneration生成使用实体框架的代码有什么想法吗？

我希望有经验的开发人员的反馈，但任何反馈都是受欢迎的。

到目前为止，我们已经做了一些研究:我们有一个精通MyGeneration的团队成员。我们观看了几个教程视频，并阅读了实体框架的介绍文档。

注意:如果实体框架是解决方案的一部分，我们知道需要为Oracle购买实体框架数据提供程序。

此外，我们知道实体空间，但由于其他原因，它似乎不是候选人。

Answer 1

如果您有一个MyGeneration导出，那么您可能需要坚持这样做。至于EntityFramework。我已经在一些小项目中使用过它，并且认为在使用小型系统(少于10-15个表)时，它是完美的。

此外，如果您正在讨论所有这些，因为没有任何“真正”适合您的解决方案，那么请考虑我的两个备选方案之一：

• 获取CodeSmith的副本并创建自己的模板。这样，您就可以从EntityFramework开始(由您生成的代码使用)，并在遇到问题时切换到其他东西。
• 考虑一下.NET层。在过去，它对我的大型项目非常有效。

Answer 2

我必须说，我对MyGeneration没有太多的经验，但在过去的6个月里，我有很多使用实体框架v1开发更小的应用程序的经验。从我所经历的映射存储过程以及只从SP返回Model导致的v1的麻烦来看，如果您想要目前最可行的选项，我建议此时使用MyGeneration。在实体框架中，仍然存在许多在v2中被解决的痛点(手指祈祷)。

Answer 3

我们使用自定义的代码生成器，这些代码生成器是从单个C#图(由制作并保存在XML中)生成的代码、SQL脚本和文件。这样，您就可以完全控制数据层中的一切。当然，只有当项目足够大并且任何其他方法不那么适用时，它才是合适的。制作这样的生成器并不太困难，在以后的阶段，您可以增强它们以生成额外的功能，例如，直接从UML图中获得web服务。