locked
Entity Framework best practice between using stored procedure for inserts or object.Add RRS feed

  • Question

  • User1830669310 posted

    I have run into some issues lately and I'm not sure which is the best practice going forward.  I have a database with many stored procedures.  Is it best practice to use those stored procedures or the object model built into the entity Framework.  i.e.

    context.customer.Add(customerobject)

    context.savechanges()

    OR

    context.AddNewCustomer(param1, param2, etc.)

    I know it is discouraged, but I did post  a similar question on the MVC forum here http://forums.asp.net/t/2057100.aspx?ViewModel+passed+into+Controller+do+I+have+to+map+it+to+the+domain+model because I'm running into the issue with an MVC project but as I have been thinking about it, this really is an EF issue.

    I welcome your input.

    WB

    Wednesday, July 1, 2015 5:33 PM

Answers

  • User-821857111 posted

    n2teeth

    Are you suggesting that performance is test against which implementation to use?

    If you fall into the group I described previously, yes. If on the other hand you already have a bunch of stored procedures that map directly to ViewModels, there's little point in mapping them to domain objects as an intermediate step. Equally, if your FormModels (what I call viewmodels that get posted back) map to Create and Update procedures, You may as well pass that formmodel in directly. I can't see any point in using the DbSet API in those cases.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, July 2, 2015 5:05 PM

All replies

  • User-821857111 posted

    I have run into some issues lately and I'm not sure which is the best practice going forward.
    It depends on what those issues are. 

    Usually, people use the DbSet API when working with EF, but you may find that sometimes the generated SQL is not good in terms of performance, so you fall back on a stored procedure instead.

    Thursday, July 2, 2015 2:10 AM
  • User1830669310 posted

    n2teeth

    I have run into some issues lately and I'm not sure which is the best practice going forward.

    It depends on what those issues are. 

    Usually, people use the DbSet API when working with EF, but you may find that sometimes the generated SQL is not good in terms of performance, so you fall back on a stored procedure instead.

    What I didn't include in the previous post was the code to map the viewmodel object back into the domain object in order to use the DbSet API in EF.  I'm struggling with the idea that writing this code to map back to the domain model object seems unnecessary because the values in the viewmodel object can be passed into the custom stored procedure that I have added to EF.  Are you suggesting that performance is test against which implementation to use?

    Thursday, July 2, 2015 1:04 PM
  • User-821857111 posted

    n2teeth

    Are you suggesting that performance is test against which implementation to use?

    If you fall into the group I described previously, yes. If on the other hand you already have a bunch of stored procedures that map directly to ViewModels, there's little point in mapping them to domain objects as an intermediate step. Equally, if your FormModels (what I call viewmodels that get posted back) map to Create and Update procedures, You may as well pass that formmodel in directly. I can't see any point in using the DbSet API in those cases.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, July 2, 2015 5:05 PM