从ADO.NET迁移到实体框架

Question

I have my project set up on ASP.NET MVC 4 using ADO.NET.

But I think that my Data Access Layer is not upto the mark. In my company, the data fetching works this way - First the indexes of all the columns of the query result are stored in variables. And then, values are fetched using those index variables. It saves times because DataReader["Name"] will be slower than DataReader[0]

But this approach makes my dev speed slow (mapping variables etc). Plus, while fetching a single record, it actually does double the work - First it gets indexes, then it fetches data, instead of just fetching the data.

I am thinking to migrate to EF.

Whatever documentation I have seen about EF, I am interpreting it in a way that, with EF, my already written Stored Procs will be of no use.

Is it so, if I migrate to EF now, I will have to write code for all my CRUD operations again?

Answer 1

There are different way to call a stored procedure. I personaly prefer to use EDMX files.

There are only few steps:

• Import Stored Procedure

• Create function Import

Here is an example where I wrapped a function import into a method:

    private static List<GetEmployees_Result> GetEmployeeList()
    {
        using (var db = new DBEntities())
        {
            //do some crazy Linq
            ObjectResult<GetEmployees_Result> listOfEmployees = db.GetEmployees("USA");
            return listOfEmployees.ToList();
        }
    }

Thats it, now compare that with the tones of ADO.NET code you need to write to do the same thing!

SAMPLE PROJECT

Answer 2

You might be doing it for the wrong reasons.

If the performance reason between DataReader["name"] and DataReader[0] makes a noticeable difference in your project, adding another layer of indirection (Entity Framework) will probably make performance worse.

However, I rather assume that this difference is not really relevant in your case, and your company is doing it out of a misdirected desire to micro-optimize.

My advise is to try EF, try using DataTables ( DataRow.Field provides type-safe access to query results), compare it with your current approach and then choose whatever makes your development life easier. In most cases, the data access time will largely dominate any "column name lookup" time, so I would not worry too much about that.