I'm using EF Core and have generated the database with migration (code first). In the meantime I have created a View in DB directly and would like to reverse engineer this views in my dbcontext file. I know I can follow this link to get the view but I don't know if this can mess up my existing dbContext class or not.
Is there a recommendation that you only need to use migrations or reverse engineering, or can you mix them depending on the use case you have.
I've always used one or the other, but having the reverse engineering feature in such a case would be great, but I'm not sure if this is a good idea.
Thanks
I would recommend you to not mix these two things. With reverse engineering, you will get a generated DB context class file, but with the code first approach, you are manually writing the context file.
Why do you want to use reverse engineering? If you want to create the entity classes for the views from the DB, you can use it, but in my opinion this is not so comfortable (you should only keep the changes that are related to the views and drop everything else).
Related
I want to implement repository pattern in my ASP.NET MVC project. I've seen a lot of implementations when searching google and I'm a little bit confused. Most of them created their own Context class which inherited from DBContext class and then injected it in a repository (or repositories) constructor.
None of the articles I found explain why the custom DBContext class is created and why they just don't use default ApplicationDbContext and HOW to change your app code to adapt to the new Context class. They don't even mention the class.
I'd rather use default ApplicationDbContext which I would inject in repository classes, because at the moment I don't see a point in creating a new DBContext class. Am I missing something? Is it a bad practice?
If, for some reason, I will have to add new DbContext class, how to edit my code (web.config and others) to adapt it? If I already made migrations to database, would change of DBContext class affect the database? Would it be necessary to do migrations once again?
To give you an example look at the MSDN documentation:
https://learn.microsoft.com/en-us/aspnet/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application
I just have no idea why the author uses SchoolContext instead of ApplicationDbContext.
it's a broad question, a guess that's the reason for the down votes.
You do seem confused. First off, I'm not an expert (see points). I did get a little bit in the weeds with the default ApplicationDbContext. Maybe you use a template where it pops up? Anyway, I launched the MVC-template and tehre's no default context class provided.
In short you create your own Context-class. You give it any name you want, given that in ends with Context AND IT INHERITS from DbContext. If not the Entity framework will not recognise it, and will not know what to do with it when building the database an so on. See your article:
The main class that coordinates Entity Framework functionality for a given data model is the database context class. You create this class by deriving from the System.Data.Entity.DbContext class. In your code you specify which entities are included in the data model. You can also customize certain Entity Framework behavior. In this project, the class is named SchoolContext.
Blockquote
By default you have only one Context-class.
It is self evident you need to create your own context-class, since you can't access the DbContext-class. (And even if you could, you should not want to do that, you need to separate the abstract and the implemented.)
I don't understand §2. ApplicationDbContext is just a way to write MySelfNamedContextClass.
§3: I don't know if working with two contect-classes is possible/feasible, but the simple implication is that you would be working with two separate databases. That's already pretty complicated, and what you're wrtiting about is not heading in that direction.
If I already made migrations to database, would change of DBContext
class affect the database? Would it be necessary to do migrations once
again?
Yes, absolutely it would. Your adding a table or a field or a constraint or a relationship to it ... .
You can do two things depending on the changes you bring:
(i) add a supplemental migration
(ii) You would have to rewind your migrations (remove-migration). It could be that you need to reset your db to your first migration (update-database 'here name of first migration without the quotation marks'. If you get stuck with that, and you're still on local db, just remove db by deleting it outright (maybe after closing solution) and rewind and rebuild the migrations and rebuild the database.
Especially for scenario (ii), if you have already data in the database (that isn't seeded into it), you would need to take measures to store it somewhere !!!
I hope this somehow answers your questions.
Kind regards.
I am working on a project using Entity Framework 5 with MVC5. My Project is currently running.
I am trying to add a column in a table. But as we know that in EF when we add a field in model it drop and recreate the database, which i can`t do.
One method for this is found code migration. But my manager is not allow me to use that(because its a big database project).
Please help me and suggest something for it.
When I start using code first with Entity Framework, I was in the same situation as you. I was always running Update-Database -F and then watching all my tables get dropped and recreated, even for something as simple as renaming a field.
Versioning databases is hard, but it's much easier with named migrations (which I think it what you mean when you refer to code migrations). I know your boss is against the idea, but it's very flexible.
Essentially you run Add-Migration -Name xxx in your Package Manager Console and Entity Framework will scaffold a configuration class for you with the default commands (both for versioning Up() and Down()) it will execute when you Update-Database. If you don't like the commands, you can change them. You can even move data around if you need to (it's a bit fiddly though).
I think you have four options available to you;
Use code-first automatic migrations: This is what you have at the moment, and doesn't give you enough control over what happens when you update your database. It's good for getting started in the earlier stages of a project, but becomes unwieldy after production.
Use code-first named migrations: Gives you the control you need via Configurations - but your boss has prevented use from using it.
Use a database-first approach: Database First allows you to reverse engineer a model from an existing database. So if you need to make a change, you would change your database first, and then regenerate your models using EF. This is usually favoured by DBA's, but it may mean that you have reimplement some aspects of your existing project.
Dont use entity framework: It's possible that you could revert back to SQL queries, which your boss might accept and gives you the flexibility you need - but who needs that kind of pain?
Let me know if I can help further.
im not sure what im looking for, and everything that i've seen so far looks like it will work till I really dive into it. I just need some pointers from the brains here. Im working an ASP.NET MVC EF5 SQL2012 project. We have a model set that isn't code first (The entities were built using the designer) and as of right now, everything is working just fine. But, we have this setup script... (Convoluted as i've ever seen) and i need to get it into something more automated. Right now, the setup script pre-populates the tables with data. look ups, reference, etc. I'm looking for a way to automate this further, without having to run this script, and even more so. To generate the database and tables automatically. Every article i've read seems to do the trick (Migrations, seeding, etc.) but the one thing they don't take into consideration, we federate services. So the actual EDMX is on a WCF Dataservice 5.6. I have access to the models and what not but the WCF service exposes an DataServiceContext which doesn't have a seed on it. Am i looking at the right stuff here? or is the only option here to have this confounded setup script (All C# Driven). This website has been detrimental to this: http://www.entityframeworktutorial.net/code-first/seed-database-in-code-first.aspx as well as this: Auto Create Database Tables from Objects, Entity Framework but i don't see how i can use these over WCF 5.6.
The short answer is that Model-First doesn't give you a seed method because they want you to use a SQL script, but you have a few choices:
Use EF PowerTools (or VS2013's EF Designer) to generate the "Code-First" model from your DB. This will allow you to seed your DB, and have finer control over how everything operates under the hood.
Use a SQL script to seed with. Generally, if you make changes to your schema, you'll re-run your recreate DB script. Create a separate script to populate your DB and keep it handy. If you feel more comfortable in code than SQL, you can make a console app (or whatever type of app you want) and keep it up to date with your schema.
If all you need is seed data, and there is a good business case to expose a method to your service consumers, you can keep Model-First, create a stored procedure to seed your DB, and expose it as an EF function. You can then expose this in your WCF service
Personally, I tend towards designing the DB myself, using VS 2013's EF6 POCO generator, then using Code-First because of the better granular control that you get with real data classes. Then I do some cleanup work, write my seed methods, etc.
In trying to separate my domain layers and GUI and looking into all the different ways to do that, one thing that I keep asking is why is this so difficult? Why all the extra code for data obejcts and then all the extra mapping of properties copying values in and out etc. Shouldn't theere be an easier way?
Then I remeembered when i used to wite small littler db app using MS Access and, Access has the concept of a Dynaset, basically a Dynaset is a View, just like an SQL Server View, except it is an updateable view. So, a MS Access form would be based of the View/Dynaset and therefore would not have to know the details of all the individual tables involved. Sounds like the Data objects pattern to me. Now, since Access has had this for 2 decades, shuoldn't there be a similar Dynaset, View, Mapping tools for Entity Framework, one that abstracts away the entities from the presentation? Is there one I am not aware of? 3rd party?
Thoughts on this?
If I understand you correctly, you may be looking for Entity Framework with POCO entities. You can find templates for them in the online gallery for templates (when you Add New Item in the project). Alternatively you can use right-click in your .edmx design view, select "Add code generation item" and pick the Fluent Generator.
These methods create multiple files instead of the default all-in-one EF generated file. One such file is the DbContext (as opposed to ObjectContext), one contains only entities (in the form of regular C# objects, no attributes or anything, just plain objects) and the last contains generated mapping in the form of fluent rules.
In this phase you can de-couple the entities file from its template and move it to another assembly. And voila, you have entities independent on the EF infrastructure. You can just pass the context these entities like you would before, and it'll do mapping by itself.
Alternatively you can use tool like AutoMapper, but you'll have to provide the mapping manually, which is a lot of work, but may be good in some cases.
Good design requires work. If it was easy, everyone would do it automatically. After all, everyone wants to do the least amount of work possible.
All the things you are complaining bout are part of the good design process, and there is no getting around them if you want a good design.
If you want to take shortcuts, then by all means, skip them. It's your code. nothing requires you to do things any specific way.
Access can do a lot of things because it's a desktop application, not a web application. Web applications are fundamentally different from desktop applications in how you design them, how they work, and what issues you face with them. For instance, the fact that you have a stateless environment and cannot keep result set from request to request makes many of the things people take for granted in Access impossible to do in a web app.
Specifically, if you want to use views, you can do so. Views are updateable if they are properly designed, but typically require update statements that only affect one table in the view). EF can work with views as well, but it has a lot of quirks you must deal with.
The data mapper pattern has emerged as a common pattern in web design because it's the easiest and straight forward way to have clean separation of concerns between layers and/or tiers. I suggest you find ways to make them work within your development process.
It may also be that MVC is not the most appropriate framework for you to use. It sounds more like you want to build Web apps the way you did Acceess, in which case Visual Studio Lightswitch may be a better choice for you.
http://msdn.microsoft.com/en-us/library/ff851953.aspx
Currently i'm updating a project from MVC 2 to MVC 4 and I'm about to swap the custom ORM/data access "layer" with EF 4.3.1 ( upgrading to 5 when it's out) and as i currently understand most of the controllers use functions from another file which are wrappers to DB queries and stored procedures.
So , my question is this : Should i delete this file with the wrapper functions and directly use EF to fetch the data from the controllers or should i just delete the contents of each function and replace it with EF code ?
Any other design tips you could give me ?
Thanks !
Using a repository pattern (exactly what you are doing) allows you be more flexible in the future as you can swap out that single file with code that uses NHibernate or connects to MySql for example. This way your code isn't tightly coupled with EF and you can more easily move away from it should you want to.
Having said that, there is obviously some coding overhead involved with the repository pattern and if you're not concerned with coupling your code tightly with EF then you can certainly go the latter route.
I think that the this is simply matter of choice, both seem valid for certain scenarios. That said, I think that for larger project using classes that simplify access to the database, provide common functionality and can be more easily swapped for classes wrapping other data providers (like Hibernate) when you would need to.
Plus you might add additional data providers (for example consuming other sites' APIs) and if you also included these data providers directly into your controllers, you would produce very hard to read code.
This approach will also significantly simplify your controllers, which might not seem as a big deal at first, but as more controllers with significantly functionality will be added, the added value becomes clear.