none
How to completely remove EF from MVC app RRS feed

  • Question

  • Visual Studio 2017, MVC5

    I want to completely remove the dependency for Entity Framework from my MVC5 app and replace it with ADO.Net

    Are there any instructions available for doing so? I googled it, and couldn't find anything.

    I do NOT want to replace it with another ORM of any kind. I just want to use ADO.

    Any help in this regard would be appreciated.

    Sunday, May 12, 2019 11:38 AM

All replies

  • Visual Studio 2017, MVC5

    I want to completely remove the dependency for Entity Framework from my MVC5 app and replace it with ADO.Net

    Are there any instructions available for doing so? I googled it, and couldn't find anything.

    I do NOT want to replace it with another ORM of any kind. I just want to use ADO.

    Any help in this regard would be appreciated.

    Just go to Nuget and uninstall it and it's gone. Sure, you can use ADO.NET and MS SQL Command objects.

    But one, are you going to start using datatables?

    https://dzone.com/articles/reasons-move-datatables

    Two, do you have any concept of SoC?

    https://en.wikipedia.org/wiki/Separation_of_concerns

    https://www.c-sharpcorner.com/UploadFile/56fb14/understanding-separation-of-concern-and-Asp-Net-mvc/

    Three, if you start using ADO.NET and SQL Command objects, then learn how to use parmterized dynamic inline T-SQL or parmterized stored procedures  for CRUD with the database.

    Four, learn how to use a DTO pattern using a single DTO or a collection/list of DTO(s) instead of using  table adapter, dataset and datatable.

    https://www.codeproject.com/Articles/1050468/Data-Transfer-Object-Design-Pattern-in-Csharp

    Five, understand the MVC UI design pattern.

    <copied>

    https://docs.microsoft.com/en-us/aspnet/mvc/overview/older-versions-1/overview/understanding-models-views-and-controllers-cs

    An MVC model contains all of your application logic that is not contained in a view or a controller. The model should contain all of your application business logic, validation logic, and database access logic. 

    A view should contain only logic related to generating the user interface. A controller should only contain the bare minimum of logic required to return the right view or redirect the user to another action (flow control). Everything else should be contained in the model.

    In general, you should strive for fat models and skinny controllers. Your controller methods should contain only a few lines of code. If a controller action gets too fat, then you should consider moving the logic out to a new class in the Models folder.

    <end>

    https://www.upgrad.com/blog/mvc-architecture-in-java/

    <copied>

    MVC architectural pattern follows an elementary idea – we must separate the responsibilities in any application on the following basis:

    • Model: Handles data and business logic.
    • View: Presents the data to the user whenever asked for.
    • Controller: Entertains user requests and fetch necessary resources.

    <end>


    • Edited by DA924x Sunday, May 12, 2019 1:20 PM
    Sunday, May 12, 2019 1:18 PM
  • The reason I want to remove it is because

    0) We use nothing but stored procs to access the database, and EF is not exactly stored-proc friendly.

    1) We have an established ado.net code-base that is equally as flexible as EF, yet has a MUCH smaller footprint, as well as being about three times faster. Our ADO class only has eight methods and they are copiously documented, and well-tested.

    2) We tried using the ADO.Net data entity mode to build EF-compatible models and contexts, but bugs in EF6, combined with bugs in the ADO Data Entity Model prevent us from using either one for our regular db work. I'm not going to bother detailing our issues, because a) the list is long, and b) you already know what issues we faced if you're at all familiar with either product).

    3) We do NOT want to use EF7, or any other ORM for that matter.

    ----

    Anyone that is even slightly familiar with using EF in conjunction with the Identity knows that "simply uninstall EF" is NOT the complete answer. What I'm looking for is a way to keep Identity, but use ADO instead of EF.

    Lastly, I don't need lessons on SoC, and this has nothing at all to do with that or the MVC design pattern. If SoC was adhered to by MS when developing the Identity code, replacing EF with something else wouldn't be such a royal pain in the a*s.



    Sunday, May 12, 2019 1:50 PM
  • 0) We use nothing but stored procs to access the database, and EF is not exactly stored-proc friendly.

    I stopped using sprocs over 10 years ago, once I discovered how to use an ORM like nHibernate and EF, becuase I had been in too many shops where those bunny rabbit breeding sprocs were all over the place with half of them no one knew what they were for or about.

    And besides if I wanted to run an sproc, then I just use the EF backdoor and run them.

    https://blogs.msdn.microsoft.com/alexj/2009/11/07/tip-41-how-to-execute-t-sql-directly-against-the-database/

    I just never found it that hard to run an sproc using EF over the years.

    https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/ef/how-to-execute-a-parameterized-stored-procedure-using-entitycommand

    One could use the IObjectContextAdapter, and sill use the Ef6 backdoor to run a sproc.

    1) We have an established ado.net code-base that is equally as flexible as EF, yet has a MUCH smaller footprint, as well as being about three times faster. Our ADO class only has eight methods and they are copiously documented, and well-tested.

    I understand that Dapper is right there with ADO.NET, since it's a micro ORM,  and it too has a small footprint. Well, I have yet to use it. But that is what they are recommending to use in the ASP.NET MVC and ASP.NET Core forums in the MS ASP.NET forums, if one doesn't want to use an ORM such as EF, nHibernate and other full featured ORM(s) and one wants speed

    https://exceptionnotfound.net/dapper-vs-entity-framework-vs-ado-net-performance-benchmarking/

    Anyone that is even slightly familiar with using EF in conjunction with the Identity knows that "simply uninstall EF" is NOT the complete answer. What I'm looking for is a way to keep Identity, but use ADO instead of EF.

    You did not mention anything about Identity, huh? 

    Nevertheless, you should be sharp enough to know how to look at the Identity schema and roll your own code.

    https://www.codeproject.com/Tips/677279/SQL-script-for-creating-an-ASP-NET-Identity-Databa

    But on the other hand,  in trying to change the AccountController and ManagerController and use ADO.NET with sprocs and all that is involved in changing those controllers  away from using EF is like chasing fool's gold.

    It is something I wouldn't be bothered with nor would I try to roll my own on it either concerning Identity. I can't say that it can't be done, but I sure as hell wouldn't be bothered with it. Myself, I would just use the Identity template and code generated,  or I  would develop my own database schema for security and code for it that didn't involve the Identity database, which I have seen done.

    Lastly, I don't need lessons on SoC, and this has nothing at all to do with that or the MVC design pattern. If SoC was adhered to by MS when developing the Identity code, replacing EF with something else wouldn't be such a royal pain in the a*s.

    My take on it is that Identity was NOT involved, since you didn't bother to mention it, and I am not an Internet Carnac the Magnificent  reading between the lines.   

     3) We do NOT want to use EF7, or any other ORM for that matter.

    If all you are doing is running sprocs, then you defeat the purpose of even using an ORM.




    • Edited by DA924x Monday, May 13, 2019 8:24 AM
    Sunday, May 12, 2019 4:26 PM
  • If all you are doing is running sprocs, then you defeat the purpose of even using an ORM.

    Yeah, I know that. That's why I'm asking the question. The ONLY reason EF is even part of the project is because that's what the project template gives you when you select "individual user accounts". Beyond the identity stuff, *all* database access is performed with our ADO.Net code,

    I stopped using sprocs over 10 years ago, 

    Well, the short version is that I don't have that option (the reasons aren't relevant to my original question).

    I simply want to replace EF with our ADO.Net stuff. I'm looking for a different (custom template, or the necessary alternative code to make it happen.

    IMHO, MS should have given us the option to not use EF when they created the MVC project template.

    Monday, May 13, 2019 1:25 PM
  • I simply want to replace EF with our ADO.Net stuff. I'm looking for a different (custom template, or the necessary alternative code to make it happen.

    The EF forum knows nothing about the ASP.NET Identity database and its usage in ASP.NET solutions, and you best direct your questions to the ASP.NET forums. 

    http://forums.asp.net/

    IMHO, MS should have given us the option to not use EF when they created the MVC project template.

    You can't be doing that much in using Identity security that it would warrant trying to do something with it other than in its current state using EF and trying to use sprocs in EF's place IMHO.

    Yeah I have seen developers in the MVC forum implement additional functionality to the Identity database, controllers and views, but that involved using the existing Identity DB using EF that is part of the Identity solution.

    Maybe, you should implement your own security implementation not involving Identity and the templets. 

    Monday, May 13, 2019 3:48 PM