I need to port an existing ASP.NET MVC app into a new ASP.NET Core MVC app but I need to maintain the current domain model, EF migrations and data (ultimately I just need the new app to work with the existing database…if I need to start the migrations from start that’s no problem). I can’t find any explanations of how to do this, and from what I’ve read it appears porting from MVC to Core MVC isn’t without it’s traps and pitfalls.
Related
At work, I use ASP.NET MVC (not .NET Core) with Entity Framework and SQL Server. However, I wanted to practice a bit with ASP.NET Core MVC and some other SQL Server stuff (like experimenting with SSIS) at home, so I set up a small dev environment for me to work in. I created my database and tables, populated it with information, and created the default template you get with ASP.NET Core MVC. No issues so far!
But then, when I went to add a model into my project, I had no option to add an ADO.NET Entity Data Model like I do at work. After googling around a bit, I saw a mention that you could not create these kinds of models in .NET Core applications: https://learn.microsoft.com/en-us/answers/questions/357012/can39t-find-adonet-entity-data-model-missing-visua.html. I did some more googling, and it seems like just about every single thing I'm finding online is that you have to use package manager console, and type it all out.
Is this really the only way? Surely there has to be something better... It was very nice in ASP.NET MVC when I could add the model, and then it would take me through a wizard to get everything set up. I could create a new connection string, test the connection to the database, select which tables/views I wanted to add to the model, and I was all set! It was just as nice being able to go into my model and easily update the model with new tables, columns, or anything else I needed.
I get that code-first solutions are more mainstream these days, but I want to stick with the database first approach. Is there a simple, user-friendly (non package-manager console) approach for me to add models like I used to, but still get the benefits of .NET Core? Any good tutorials out there to get me on the right track (that aren't code first)? I appreciate anyone who can point me in the right direction!
I have a database that has been in place for a few years. One of our web apps uses Membership Provider and the tables in the database that were created when it was setup. This older app uses MVC 4.0.
I have a new web app that I am creating that needs to use the same database. When I created the project, it used MVC 5.
The new app does not need to use the same logins as the older application but it does need to use the same database for other data in it.
This is where my problem lies. Should/could I use Membership Provider since that is what my users are already using on the other application on the same database this app will be connecting to? Or should I be using Asp.net identity? Can I mix them between applications like that? Should I downgrade my app to use the same MVC version as my older app?
I'm kind of lost as to what path I should take at this point. Any guidance would be greatly appreciated!
Your title says MVC6, but in your question you only talk about MVC5. As far as I'm aware, ASP.NET Membership is completely incompatible with ASP.NET Core (MVC6, although it's no longer called that). However, you can utilize Membership with MVC5. Regardless, ASP.NET Identity is the way forward, so any new application should use that, and updating older apps to move to Identity should, at the very least, be in your pipleline.
I have used MVC thus far in a traditional EF sense by creating POCO first objects and then adding this to a database context but I have a new problem in that I am trying to recreate a legacy system but using the MVC framework but it uses a connection to multiple different databases and tables.
In the legacy solution they use Enterprise library to create the link to databases but I am not sure that this is the best option available and was wondering what are the options open for dbconext in regards to different database connections at the same time, is this possible?
The question is nothing to do with MVC. Besides, ASP.Net MVC (Presentation Layer) should not even need to know about what kind of ORM or database at Data Access Layer.
Back to original question, it is not worth using Entity Framework, if you have to query two databases at the same time.
I suggest you want to look at other ORM like Dapper.
I have been given the task of trying to convert our company's existing ASP.NET Web Forms application into an MVC 4 application (as an R&D starting project). I have a little experience with MVC 2, but my issue is trying to actually get started. We have existing stored procedures that we access via Subsonic as our ORM (so that they can be called in our code). We also have a Data Access Layer that is tied in with Subsonic.
I know this is kind of a vauge question, but is there a known way I can use our existing stored procs and tables with a different ORM (such as NHibernate or something) to start creating this MVC application?
Thanks for any help provided.
There should be no reason that the SP's need to change just because the ORM changes; you may want to to improve some of what you are doing and rewrite some of them, but not because the ORM changed.
I am starting out on a project that will involve ASP.NET MVC using a legacy ODBC 2.0 compliant database. The goal is to replace current system functionality with a web front end over a period of maybe a year then swap out the backend with SQL Server.
The plan would be to code against SQL server then insert some shim into the repository classes to use ODBC instead. Is it even feasible to do this ? Entity Framework doesn't have built in support for ODBC.
Any thoughts or advice would be appreciated.
I personally use NHibernate with MVC. Originally I picked it up because our database doesn't support EF but enjoy it enough that even if we moved to SQL Server I'd keep NHibernate.
The learning curve is kinda weird. It is definitely steep to become an expert, but it is interesting in that it is pretty organic to let it handle more and more of the work for you as you get comfortable with certain layers.
So for your case NHibernate probably supports your database, can be used as a simple data access layer (just returning DTOs), provides a database agnostic interface and can support SQL Server when the time comes. If you end up wanting more out of NHibernate it is there when the time comes.
There's nothing to stop you writing your own data access layer, to query the ODBC Database. You could also make your own entity layer so that the MVC model can populate your entities using the data layer, and return these objects to the controller.
Basically, have a data access and entities layer under your mvc app, then you can replace these entities, with entity framework, or nhibernate entities, at a later date.
This way of doing it means that your MVC app doesn't need to know what database it is using, it also means that you should have an easy time when you switch an entity later.