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

Is it possible for EF6 to produce my model objects from a ref cursor that an Oracle stored procedure has returned?

So, the MVC5 transition from webforms is currently taking place at my present place of employment.

We want to make use of Oracle stored procedures with EF6. Many of the models we wish to use will involve choosing information from many tables (our database is massive). Additionally, we already have certain stored routines.

Either I need to be able to directly tell EF6 which database each of my models attributes is coming from, or I need to be able to tell EF6 to map my models to the output of a stored procedure.

The alternative choice is to develop individual Oracle views for each model.

I've been searching online for a long, but I can't seem to locate a means to get what we need done.

We previously used a bespoke DAL/ORM while using webforms. But we really want to use Entity Framework instead.

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

Accepted Answer

It appears that what I was attempting is not supported. Only create, update, and delete stored procedures are supported by EF6. We're hoping to come up with a standard method of utilizing MVC5 with the Oracle DB that we already have.

I appreciate your efforts, T McKeown; the links you provided helped me reach my decision.

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

Popular Answer

You have two basic options here:

Code Initial:

Create your models and "wire" them to the manual methods you described.

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 initial:

By pointing the EF at your database, models based on your schema will be generated for you. Your custom procedures can always be called using Helper classes, etc. The required attributes would be extracted from the EF model and passed in.

Personally, I like to start by coding basic POCO objects and then wire them together how I see fit. This allows you the most flexibility, but if you don't initially establish an architecture and follow basic guiding patterns, it could go out of control.

When it comes to huge volume applications, boilerplate MVC techniques, like Ruby-On-Rails, can become cumbersome as they expand. Dynamic SQL will never be able to compete with using effective procedures for CRUD.



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