我对在我们的场景中仅使用实体框架与存储过程的合理性有疑问。
我们计划拥有一个 N 层架构,包括 UI、BusinessLayer (BLL)、DataAccessLayer(DAL) 和 BusinessObjectDefinitions(BOD) 层。 BOD 层为所有其他层所知,并且在 DAL 中执行查询的结果应在传递到 BLL 之前转换为对象(在 BOD 中定义)。
我们只会对所有 CRUD 方法使用存储过程。
因此,在选择存储过程的情况下,我们将添加一个函数导入,创建一个复杂类型,当我们执行该函数时,我们将复杂类型的值转换为 BOD 类并将其传递给 BLL。
因此基本上,模型中没有实体,只有复杂类型,它们会转换为业务对象。
我不确定这是否有意义,因为在我看来,我们失去了 EF 提供的很多好处。
或者我完全错了?
如果我只使用存储过程,我就不会使用 EF。
就我个人而言,我会考虑 PetaPoco、Massive 甚至直接 Ado.Net
EDIT
这是 PetaPoco 消耗 SP 并输出自定义类型的示例
http://weblogs.asp.net/jalpeshpvadgama/archive/2011/06/20/petapoco-with-stored-procedures.aspx http://weblogs.asp.net/jalpeshpvadgama/archive/2011/06/20/petapoco-with-stored-procedures.aspx
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)