I'm starting a new project and want to use EF Code First pattern but I also want to use the repository pattern. I have been looking for a way to generate the repositories from the dbcontext models but all answers I've seen so far are for generating repositories from .edmx or DB. I don't want to create an .edmx.
The steps I want to do is this:
1. Write models
2. Generate repositories using t4 templates
3. Write app code from models and repos
4. Run Add-Migration to add migration code
5. Run update-database to update based off migration code
What could I use to tell it to generate t4 templates based on the model classes?
I've found how to do it now. Using T4Scaffolding, I am going to be able to generate the repositories as I need. It also allows me to override the default t4 templates and create custom scaffolds too.
There is a NuGet package I created which does this as well, it requires a namespace your models not a edmx file:
https://www.nuget.org/packages/RepositoryGenerator/
Related
Iam using EF 6 with database first .. and every time I update the scheme : all my editings to the edmx file (mainly for defining db built in functions) are lost .. but using code first I can add my dbmodelbuilder calls in a separate file with partial class .. and by that I can also use all the nuget packages that targets code first such as EntityFramework.Functions.
Thanks for helping
You can use Code First from database option when you are creating your ADO.net entity data model. This will give you the code first classes that you can edit.
After creating your model you would need to stick to using the code first model otherwise you will need to regenerate your code-first after every database change...
Download the EF tools here.
I have below structure of classes:
SecurityLayer.Domain dll
User class and some other classes
Has a nuget package for this
SecurityLayer.Data dll
SecurityDbContext class (which inherits from DbContext and manages User related entities
Has a nuget package for this
Now I build another product which uses two packages above. And I have below structure
MyProduct.Data dll has a ProductDbContext to manage entities from MyProduct.Domain dll
The problem is when I use Add-Migration on MyProduct.Data project, EF generates a migration to create ALL entities from both MyProduct.Domain and SecurityLayer.Domain
I know that EF6 support multiple DbContext in a single database, but it does not work for me. Can we do something to let EF avoid entities in SecurityLayer.Domain? Any advice is much appreciate. Tks a lot!
The easiest way would be to create your initial migration and remove the bits from it that are not relevant. Subsequent migrations will not pick up the existing tables due to the way EF works.
Migrations actually store the state of the database in a table called __MigrationHistory. One of those columns contains a zipped up EDMX file. You can extract the content as a blob, save it as a .zip file and see for yourself. Each migration uses that to determine what has changed since the previous migration.
I currently use EF6 and use the model first approach. As I understand it, EF7 will be moving away from using an EDMX, and going from a more code-first approach. Now I know I will still be able to reverse engineer from my database into classes if need be.
However one thing I am not sure about is any manipulation I currently do with EF6 will be supported in anyway in EF7.
At the moment, I write T4 templates that read through the EDMX, pick up on the entities, and create new classes based on them. For example, I create partial classes for each entity that has deep clone methods in them. I also create repository classes based on the entities and create methods for finding by primary key, based on which properties in each class have been identified as the primary key.
If I lose the EDMX, does this mean I need to go back to manually creating these? Or is there another way?
If you want to keep using T4 templates, you can switch to something like CodeFirst -> ReverseEngeneer approach.
You update model in code, generate new migration, test it on a database and then use a reverse engeneer code first approach (http://msdn.microsoft.com/en-US/en-en/data/jj593170.aspx) to generate everything else. Theoretically it can be automated.
In my team we do it manually, but we do not need migrations, only a code first contexts and a lot of additional things, that T4 generates whery well.
Yes, you can still use T4 templates with Code First, We navigate Entity Classes instead of the EDMX Model, .
I have been looking at VS2015 recently and having some issues with T4 and asp.net 5 and related projects (FileManager hangs for multiple file outputs and you will need the latest version of Visual Studio, currently Update 1)
I'm following an MSDN article on applying the Repository Pattern and the Unit Of Work Pattern to Entity Framework, but I'm stuck at the mapping between the custom-made domain models and the as-yet-nonexistant database.
The article has me create two simple POCOs, Employee and TimeCard. It also walks through creating generic repositories and custom implementations therein. (I'm using the custom repositories so I can try to keep EF dependencies in the data access assembly.) However, they sort of glaze over an important step in the mapping. The article says:
With the POCOs in place we can create an Entity Data Model (EDM) in Visual Studio (see figure 1). We will not use the EDM to generate code for our entities. Instead, we want to use the entities we lovingly craft by hand. We will only use the EDM to generate our database schema and provide the metadata EF4 needs to map objects into the database.
The "Figure 1" it references is here:
But that's all it says on the subject. There's an aside on how to generate POCOs from an EDMX. There's lots of information via Google on how to generate POCOs, generate EDMX from a database, etc. But in this walk-through we already have the POCOs and I need to use them in the EDMX which would, in turn, generate the database (I'm assuming, based on other code-first walk-throughs).
I've added an "ADO.NET Entity Data Model" to the project, which is basically a blank canvas. But I'm not seeing how to add my existing POCOs to that canvas. Do I have to re-create them manually on the design surface (which would be a pretty significant duplication problem in a larger domain)? If so, how do they map to the existing ones?
Typically when you use the designer the flow is the opposite - you create the model with the designer (or create/update the model from the database) and then the code is created for you. The created code can be either the EF1 style code with entities derived from EntityObject and attributes etc. which is created with a Single File Generator which is a part of VS (Code Generation Strategy set to "Default") or the code can be created with T4 templates (Code Generation Strategy set to "None") in which case you need to add T4 templates to your project. EF matches POCOs with Entities from the edmx file by convention (names of entities have to be the same, names and types of properties have to match etc.). In the article for some reason they went the opposite way which is weird since it requires that you create all the entities and relationships with the designer manually (since the designer does not know how to create entities from the code) and make sure that the requirements for the conventions (you may not even be aware of some of them) are met. However when you start with code the better approach is to use the EF Code First approach and skip the designer entirely. Code First can create database from your code. It also contains migrations feature which allows evolving your database along with your code. Finally (as you seem to use Visual Studio 2010) you could use EF6 which allows using all the goodness that was previously only available on .NET Framework 4.5 to be used on .NET Framework 4. See here for more details: http://entityframework.codeplex.com/
*the names are going to change in the new version designer that supports EF6 and works with Visual Studio 2012 and Visual Studio 2013
EDIT to address questions from the comment
If you would like to use Code First would use the DbContext API which is a streamlined wrapper of the ObjectContext API. Here is a walkthrough that should help get you started.
You can still use Code First if you have an existing database - the difference is that you will not be able to use migrations. The easiest way to get started with this is to use EF Power Tools. Take a look at this tutorial to see how to do that.
More help here
I am writing my first WPF and EF application. I am using SQL CE database and I have added few tables to the DB. The EF diagram is generated and now I want to generate the classes. I am new to EF and MVVM both.
When I right-click on a Table diagram, it gives option "Add Code Generation Item..". On selecting it, there are two options:
Add Entity Object Generator
Add Self-Tracking Entity Object Generator
I want to know what is the difference between the two. Which one should I use? I also want to know which one is latest and what is POCO?
A POCO is a Plain Old CLR Object... a simple class that has only properties.
http://en.wikipedia.org/wiki/Plain_Old_CLR_Object
There are 3 approaches that the Entity Framework delivers.
Model first (you create a model in visual studio and generate the database)
Database first (thats what you do, you generate a model from a existing database)
Code first (the newest one, you just write you POCOS and the entity framework generates the database)
I think it is enough to generate the diagram from database. The context and models should be available after this.
Neither of those is the POCO generator. The best way to get that is to install Entity Framework 4.1. You'll then see some new options in the list to add a code generation item.
I'm a pretty big fan of the DbContext/POCO generator added in 4.1 as the code it creates is VERY easy to work with compared to the older stuff, and it works well in a DB First setup like you're using (which is also what I use).
You can give this code generator a try:
http://salardbcodegenerator.codeplex.com/
It generates data annotations and implements INotifyPropertyChanged for CodeFirst approach.