Can EF6 generate my model objects from a ref cursor returned by an oracle stored procedure

asp.net-mvc-5.1 c# entity-framework-6 oracle stored-procedures

Question

Can EF6 generate my model objects from a ref cursor returned by an oracle stored procedure??

So my current workplace is in the middle of a switch from using webforms to MVC5.

We would like to use EF6 and Oracle stored procedures. A lot of the models that we want to implement will be selecting data from multiple tables(our database is massive). We already have some stored procedures already as well.

I either need to be able to tell EF6 to map my models to the results of a stored procedure or explicitly tell EF6 which table each of my models attributes is coming from.

The other option would be to create oracle views for each model.

I've been googling around for a while and I'm having a hard time finding a way to accomplish what we need.

Before, when we used webforms, we were using our own custom DAL/ORM. But we would really like to switch to using Entity Framework.

1
1
2/11/2014 6:36:01 PM

Accepted Answer

It seems what I was trying to accomplish isn't supported. EF6 only supports create/update/delete stored procedures. Hopefully we can figure out a standard way of using MVC5 with the oracle DB we already have in place.

Thank you T McKeown for your efforts, your links helped lead me to my conclusion.

0
2/11/2014 6:35:36 PM

Popular Answer

You have 2 fundamental choices here:

Code First:

Design your models, and "wire" them up to your procedures that you have defined manually.

http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx

http://entityframework.codeplex.com/wikipage?title=Code%20First%20Insert%2fUpdate%2fDelete%20Stored%20Procedure%20Mapping

Database First:

Point the EF at your DB and models will be created for you using your schema. You can always call your custom procedures using Helper classes etc.. You would pass in the EF model and extract the attributes needed.

Personally, I prefer to code first simple POCO objects and wire them up as I see fit. This gives you the most flexibility however it can get out of hand if you don't lay down an architecture first and abide by some governing patterns.

As for performance for high volume systems, similar to Ruby-On-Rails boiler plate MVC approaches can get unwieldy as they grow. Using efficient procedures for CRUD will always win out over dynamic SQL.



Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow