仅带有存储过程的实体框架 [英] Entity Framework only with stored procedures

问题描述

在我们的场景中，我对仅将实体框架与存储过程一起使用是否合理存在疑问。

i have a question about the reasonableness of using entity framework only with stored procedures in our scenario.

我们计划建立一个具有UI的N层架构， BusinessLayer（BLL），DataAccessLayer（DAL）和BusinessObjectDefinitions（BOD）层。 BOD层为所有其他层所知，在传递给BLL之前，应将DAL中执行查询的结果转换为对象（在BOD中定义）。

We plan to have an N-tier architecutre, with UI, BusinessLayer (BLL), DataAccessLayer(DAL) and a BusinessObjectDefinitions(BOD) layer. The BOD layer is known by all other layers and the results from executes queries in the DAL should be transformed into Objects (definied in the BOD) before passing into the BLL.

我们将只对所有CRUD方法使用存储过程。
因此，在选择存储过程的情况下，我们将添加一个函数导入，创建一个复杂类型，并且在执行该函数时，我们将复杂类型的值转换为BOD类，并将其传递给BLL。 。
因此，从根本上说，我们在模型中没有实体，只有复杂类型可以转换为业务对象。

We will only use stored procedures for all CRUD methods. So in case of a select stored procedure, we would add a function import, create a complex type and when we execute the function, we tranform the values of the complex type into a class of BOD and pass that to the BLL. So basicly, we have no Entities in the Model, just Complex types, that are transformed into Business Objects.

我不确定是否所有这些从某种意义上说，因为我认为，EF提供了很多好处。

I'm not sure if that all makes sense, since in my opinion, we lose a lot of the benefit, EF offers.

还是我完全错了？

推荐答案

如果我刚刚使用的只是存储过程，则我不会使用EF。

I would not use EF if all I was just using was stored procs.

我个人认为在诸如PetaPoco，Massive或什至直接Ado.Net之类的东西上

Personally, I'd look at something like PetaPoco, Massive or even just straight Ado.Net

编辑

以下是PetaPoco消耗SP并输出自定义类型的示例

Here's an example of PetaPoco consuming SPs and outputting custom types

http://weblogs.asp.net/jalpeshpvadgama/archive/2011/06/20/petapoco-with-stored-procedures.aspx

这篇关于仅带有存储过程的实体框架的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！