I am beginning a new project, so one of the tasks given to us is to determine whether we should create one large Entity Framework 4 model (don't know how many tables yet), or split the model into separate models, one per module within the application.
If we create separate models, we'll have repeated entities within each module, but this way we have less grouped entities, less potential performance problems, etc.
So if anyone can provide insight or their experience when setting up EF models I would appreciate it. What are the pain points to be aware of?
Thanks.
imho you should consider POCOs and only use the entity models to be able to create objectcontexts.
In this way you can have the same POCOs for all modules (put them in a shared assembly) but still have different entity models in each module.
POCO = Plain Old CLR object = Regular .net class
Entity Model = Model generated by EF framework containing all objectcontexts.
POCOs in EF4: http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx
Related
I had a conceptual question about EF.
I am pretty new to the idea of an ORM in general, so I wanted to get some clarification on somethings:
I have an existing database, and I want to convert the data I am pulling from that data into objects that my application can interact with as objects, rather than just data.
An ORM will accomplish that, correct?
In EF can I create methods specific to my objects? For instance, can I make it so my application can call something like employee.ViewDetails() Where employee is an object?
If so, is there a simple tutorial you could recommend?
Is EF portable between applications? Meaning, is it easy to build an EF structure and then port it to multiple applications?
I can just do that by referencing it from different solutions, no?
Thanks for all the help
Before Answering your Question let me give you short brief about Entity Framework
Using the Entity Framework to write data-oriented applications provides the following benefits:
Reduced development time: the framework provides the core data access capabilities so developers can concentrate on application logic.
Developers can work in terms of a more application-centric object model, including types with inheritance, complex members, and relationships. In .NET Framework 4, the Entity Framework also supports Persistence Ignorance through Plain Old CLR Objects (POCO) entities.
Applications are freed from hard-coded dependencies on a particular data engine or storage schema by supporting a conceptual model that is independent of the physical/storage model.
Mappings between the object model and the storage-specific schema can change without changing the application code.
Language-Integrated Query support (called LINQ to Entities) provides IntelliSense and compile-time syntax validation for writing queries against a conceptual model.
Going Back to your first Question
Yes
Entity framework is useful in three scenarios.
1- First, if you already have existing database or you want to design your database ahead of other parts of the application. (Which is your current case)
2- Second, you want to focus on your domain classes and then create the database from your domain classes.
3- Third, you want to design your database schema on the visual designer and then create the database and classes.
2) in EF can I create methods specific to my objects? For instance, can I make it so my application can call something like employee.ViewDetails() where an employee is an object? If so, is there a simple tutorial you could recommend?
Yes Sure Take a look on this:
- https://msdn.microsoft.com/en-us/library/dd456847.aspx
- http://www.asp.net/mvc/overview/older-versions-1/models-data/creating-model-classes-with-the-entity-framework-cs
3) Is EF portable between applications? Meaning, is it easy to build an EF structure and then port it to multiple applications? I can just do that by referencing it from different solutions?
you might need to Implementing the Repository Patterns
Have a look at this Amazing tutorial
http://blog.gauffin.org/2013/01/repository-pattern-done-right/
http://rycole.com/2014/01/25/entity-framework-repository-pattern.html
Hope this helps!
Wish you the best :)
Blubberbo,
There are various ways to work with EF, they are Code First, Model First and Database first.
More information can be found in the below SO post.
Code-first vs Model/Database-first
1) You can use LINQ to SQL or LINQ Objects in context with an ORM like EF to interact with Objects.
2) If you would like methods specific to specific types, then you might want to take a look at writing extension methods for specific types.
More information here
https://msdn.microsoft.com/en-us/library/bb311042.aspx
3) To make it portable, you might want to build abstractions around it, like for example you might want to write repository classes to separate the DB layer that uses EF and the layer that calls it(a.k.a the repository layer).
More info can be found here
http://www.asp.net/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
Hope that helps,
Praveen Raju
Let's say I have a set of classes that I want to share across multiple projects. For instance, I could use them in a REST service and also in a client that consumes that service.
So I create the following projects:
MyOrders.Models
MyOrders.RestApi
MyOrders.Client
Both the RestApi and Client projects have dependencies on the Models project.
The RestApi is using Entity Framework (code first) so normally you'd decorate the model's properties with things like [NotMapped] and [Key]. However, I don't want the Client solution to have any dependency on Entity Framework. None. So I can't decorate the models' properties with EF-specific attributes.
So my question is, is there some way to correctly set the models' EF-specific attributes from the RestApi project instead, maybe in the Context's constructor or something?
You can have the POCOs in your Models project, keep them totally ignorant of Entity Framework, and do the mappings in a separate project or in the RestApi project itself.
You can do this by the fluent mapping API, for instance in the OnModelCreating override of the context that you create in the EF-aware project:
modelBuilder.Entity<Order>().HasKey(o => o.OrderID);
modelBuilder.Entity<Order>().Ignore(o => o.OrderTotal);
etc.
This is a good argument for using custom Data Transfer Objects that are independent of the table-like entities. Although it can feel like overkill to have nearly duplicate classes - one as DTOs and one as EF Entities - there is another long-range benefit: the two sets of classes can vary independently. Let's say that you change the table table structure, but the client doesn't need to know about this change. Update the EF Entity but you leave the DTO alone, though you may have to update how you map from EF to DTO.
Speaking of mapping: EmitMapper can be a great help in transferring between the two types of objects.
You need to split your data access models from the rest of the application using Data Transfer Objects.
This will give a lot of benefits. At first it will look if your duplicating all the code of the model. But when your application grows, you will find that need the data in a view which is formatted in another way than how it was or is stored the database. Validation attributes can be added in a very specific way just the way you need it.
Mapping in between them can be done various ways. By hand or by using a tool like AutoMapper
This question already has an answer here:
ORM Entities vs. Domain Entities under Entity Framework 6.0
(1 answer)
Closed 7 years ago.
I start using Entity Framework about a year ago using Database-First approach. While reading and doing research online, I came across some terminologies that are confusing me. I was wondering if someone can help clear up some questions I have:
1) Using Database-First approach, I build my SQL Tables and create my edmx file from the database. From there, I start coding by create a Data Context and then accessing the entities. I recently read and see that I can right click in the .edmx file and "Add Code Generation Item" and then add "Ado.Net EntityObject Generator/EF 5.x DBContext Generator/EF4.x POCO Entity and etc. What is the purpose of these different code Generators? Am I suppose to implement them? When should I implement them?
2) I'm reading a lot about "object model and domain model". Is EF an object model or domain model ORM?
Thank you in advance for any information.
Add Code Generation Item
By default classes are generated with the help of EntityModelCodeGenerator. With the help of custom code generation, you can customize this. Why you would want to do ?
One example I could give from top of my head is - if you want to implement INotifyPropertyChanged interface by every single entity generated by EDMX. By default EntityModelCodeGenerator would not do that for you. Thus, you would want to customize this.
(Please note this is just my theoretical knowledge however the above example is quite a practical situation)
Domain Model vs Object Model.
Regardless the difference one thing for sure is Domain Model is Object Model too because in both cases you are defining classes, and association. This is how I define Domain Model and Object Model.
The only major difference could be how you are defining objects; in case of Domain Model, you are completely thinking from Business point of view and defining your objects.
From what I see that it is probably EF Database first is Object Model because when I am doing Database designing I am less thinking about Business, rather I am thinking about what is to be stored.
If am making POCO then I probably will be thinking from Domain Model point of view.
In case of EF - Code First, I have started thinking from Business point of view and make my association, then after I think of how objects will be stored.
So it is just a perception and at the end whether Domain Model or Object Model, ORM i.e. EF will provide you to persist this object into the database.
I hope it helps.
You don't normally need to use the "Code Generation Item" option. It is used to perform changes in the version of EF being used, and you could use it to do some custom code generation. In general, you should be able to leave this option alone.
EF is really an ORM (Obect-Relational Mapper). It takes objects and maps them to relations (tables). It can be used as either an object model or domain model (or both) as well depending on how you define those terms.
I have two databases that are almost identical in schema but seperate in the data that is held within them. The consuming application does not need to know about these differences so I am creating a service which will have the entity framework models but I want it to return a single type back. For example:
**DatabaseA** -> EFModelA
- Customers
- Orders
**DatabaseB** -> EFModelB
- Customers
- Orders
I want to be able to return a Customer class through the a call rather than it returning either EFModelA.Customer or EFModelB.Customer.
I have have looked into two ways of doing this but can't work out which way will provide the least resistance in terms of maintenance. They are:
Create a unified view of the data in DatabaseA which unions the data from DatabaseB so they application only sees one entity set. The downside is working out how to make sure that they keys are unique but I can add an extra field to denote which database it came from.
Have 2 separate EF Models and have some way of scripting (e.g. T4 templates) a combined model of equivalent types and then implemented mapping code between the two EF types and the combined type.
Has anyone else come across this problem and how have you solved this? If not, how would you tackle this problem?
So I'm just getting started with Entity Framework. I'm working with a very large, existing database. I find myself wanting to use EF to create models that are "slices" of the whole database. These slices corresponde to 1 aspect of the application. Is that the right way to look at it, or should I try to model the whole database in 1 EDMX?
Let me give you a fictional example:
Suppose that 1 of the many things that this database contains is customer billing information. I feel like I want to create an EF model that just focuses on the tables that the Customer Billing module needs to interact with. (so then that model would NOT be used for other modules in the app, rather, those same tables might appear in other small EF models). This would allow me to leverage EF's conceptual model features (inheritance, etc) to build a view that is correct for Customer Billing, without worrying about that model's effects, on say Customer Support (even though the 2 modules share some tables)
Does that sound right?
It sounds right to me. The point of an Entity Model, after all, is to provide a set of persistence-capable business objects at a level of abstraction that's appropriate to the required business logic.
You should absolutely create entity models that support modules of the application, not models that copy the underlying database schema. As the link above describes, separating logic from persistence is one of the primary purposes of EF.
I would prefer to use a slice approach, based of following reasons:
If you have a massive database with loads of tables, then it would be difficult to manage massive Entity Model.
It is easier to maintain application / domain specific entities, as entity framework is not a table to entity mapping, you can create custom entities and also combine and split tables across entities.