I understand in Entity Framework you can specify relationships that need to be joined with Include:
Product firstProduct =
db.Product.Include("OrderDetail").Include("Supplier").First();
But we have the opposite issue that a simple LINQ statement is getting making too many JOINs on the SQL server.
So how do we do the opposite, i.e. tell Entity to not do any deep loading of joined tables when it gets all the orders, so that on the SQL Server it executes:
SELECT * FROM Orders
The Entity Framework often goes ahead and loads basic relationship information too.
It does this so users can make updates easily, without violating the EF's unique concurrency policy for relationships.
You can turn this off however by doing a no tracking query.
See Tip 11 - How to avoid relationship span for more information for more information
Alex
Related
I am designing a RESTful API and my questions is the following: What is the best practice for managing relationships using POST and PATCH in a RESTful API? Where and when should I allow the consumer of the API to establish relationships between entities when the opposite entity/entities already exists/exist? My goals are to (a) minimize code and code maintenance with (b) a balanced ratio of easiness to understand the API and number of API calls to establish relationships. The most limiting criterion is that I am developing and maintaining the API on my own.
If it is of any interest, I am using ASP.NET Core and separated the API (with outer facing models) and the entity framework based data layer (with data models) into two different layers, where the API layer references the data layer (API -> Data).
I would like to discuss all possible combinations of the http request methods POST and PATCH and the three types of relationships one-to-one, one-to-many and many-to-many.
POST one-to-one
I was thinking about allowing the consumer of the API to let the POST request for the new entity only go through when the opposite entity has no relationship to any other entity of the posted entity type.
Another option would be to never allow setting relationships through POST but only let it update via PATCH. I favor this option, because it makes the entity easier and saver to create when treating the relationships separately. Even better, it would only require two API calls - one for POSTing the new entity and one for PATCHing even multiple relationships to many different one-to-one opposite entities.
POST one-to-many
One option would be allowing the consumer of the API to let the POST for the new entity only go through when all of the opposite entities have no relationship to any other entity of the posted entity type. Less save would be to allow the consumer to override existing relationships of the opposite entity to another entity of the type of the posted entity.
Another option would be to not allow posting any relationship of a single entity to many entities, because the relationships are effectively set in the opposite entities anyway. I prefer to only allow setting the relationship in the opposite entities via PATCH since this is the place where the many to one relationship is effectively established, and it keeps the creation of the entity separated from establishing relationships.
POST many-to-many
I would never allow to set a relationship for a POST request in a many-to-many relationship, but only allow to PATCH new relationships on both the new entity and the opposite entity. Due to the complexity of this type of relationship, I think it is best keep the entity creation as easy as possible and manage relationships separately through PATCH requests.
PATCH one-to-one
I would set no restrictions and allow the consumer of the API to set the relationship freely on both sides.
PATCH one-to-many
This one is a real dilemma for me - number of API calls vs easiness to understand relationships and lines of code.
On the one hand, I could allow to PATCH from the single entity point of view (it contains for example an array of opposite entity IDs). This would require only one API call to update the relationships of the multiple opposite entities, but this requires more code, because the data layer needs find and loop through all opposite entities. In addition, updating from the single entity point of view is sometimes hard to understand for me - many times its easier for me to establish the relationships in all opposite entities that refer to the same single entity.
On the other hand, I could allow the consumer of the API to update all opposite entities individually. This would require many API calls, but I sometimes think updating from this point of view is easier to understand, and the relationship is effectively set in the multiple opposite entities anyway.
I don't know what to favor yet. I am thinking about offering both options.
PATCH many-to-many
The only way I can see is to allow the consumer of the API to allow setting relationships on both sides due to the nature of this relationship.
While elaborating my ideas above, I think the best guideline is to keep creation of entities completely separated from establishing relationships and to set the relationships only where they are effectively established (mimicking SQL table behavior). I assume the latter one is what most API consumers should be familiar with and the first one keeps the API save and simple (at the cost of efficiency).
Please let me know if I missed any cases, criteria for decision making or didn't think of any implementation strategies.
Best regards,
philippfx
I have been looking into some Entity framework tutorials and I have come across the word Entity Graph. I haven't got a clear idea about this term and its use. Can anyone provide info on this topic like what it is and its use in the context of entity framework?
When instantiated objects are joined together in a relationship they are referred to as
a graph, or an entity graph. The Entity Framework has some important rules about how
graphs are maintained.
Example, if you have a User(Entity) graph that consists of a User with Roles, Features.
When you detach the User
The User will be disconnected from this graph and the releationship references (Graph edges) will be destroyed.
You cannot travel from User to Roles/Features, because the graph edges (releationships) are destroyed.
I recommend you buy the "Programming Entity Framework DbContext" book (author: EF-Queen Julia Lerman) and you will find there a good explanation:
http://shop.oreilly.com/product/0636920022237.do
Google is your best friend here:
See this article for general definition and explanation of graphs
See here for specific information on EF and entity graphs
In Jpa hibernate fetching entities with associtions has always been a question for performance. Lazily loading associations with in a transaction again and again results in n+1 select issues and to avoid such issues JPQL join fetch and Criteria api joins are used. But fetching data with these two also result in Cross join issues means Cross join of all table records are returned to apllication by hibernate. Also altering fetch variable defined in annotaions on entity level is also not a good option for some cases. Hence to solve the above two issues entity graphs has been intoduced. All nodes defined in entity graphs are always eager fetched irrespective of their definition on entity level. These graphs are passed as a hint to queries . By passing graphs as a hint Cross join issues are solved as well as run time alteration of fetch behaviour can take place. For code you can check my github repository :
https://github.com/vaneetkataria/Jpa-Hibernate/blob/master/jdbcToJpaMigration/src/test/java/com/katariasoft/technologies/jpaHibernate/entity/fetch/entitygraph/dynamic/MultiInstructorsDynamicEntityGrpahTests.java
I am new to .NET and early in the design process of a front-end application for a database, and looking for some advice.
I am not sure I get it...
The DB is very strongly normalized, but provides lots of stored procedures to abstract the logical model (ex. Select sproc returns one data set from multiple tables closely reflecting the business object, Insert/Update sprocs to multiple tables, etc..)
How should I design the DAL ?
I'm not sure what the benefit of the Entity Framework is in this context.
When generated, it reflects the normalized DB schema rather than an abstraction of it.
Or if I map the sprocs to generate it (which requires some work since the T-SQL in the sprocs is dynamic and with joins), I get the business objects alright but can't see the benefit of it : the entities represent to a single 'abstract' table, and not a set of entities with Datarelations, the sprocs handles the calls to multiple tables. It seems more work to map the generated change events to the sprocs than to call the sprocs directly.
What am I missing ?
Thanks,
Michael.
You can do this with the EF, but the designer won't help you; it doesn't know how to derive an entity type from a stored proc signature. You would need to write the EDMX by hand. CTP 4 code-first may be easier, but I've never tried it.
After some research, I think I'm starting to be on the right track.
The following articles were very helpful :
Entity Framework Modeling: Table Per Hierarchy Inheritance
see also : Entity Framework Modeling : Entity Splitting
To be clear, what I wanted was to abstract the DB schema in the EF model.
(I didn't want any entity representing 'nothing', like a many-to-many relationship).
Besides these modeling techniques, I used views to generate the EF model, and added sprocs for CRUD.
As I said, I am a beginner. Let me know if I am on a wrong track...
I've been trying to familiarize myself with the Entity Framework. Most of it seems straight forward, but I'm a bit confused on the difference between eager loading with the Include method and default lazy loading. Both seem like they load related entities, so on the surface it looks like they do the same thing. What am I missing?
Let's say you have two entities with a one-to-many relationship: Customer and Order, where each Customer can have multiple Orders.
When loading up a Customer entity, Entity Framework allows you to either eager load or lazy load the Customer's Orders collection. If you choose to eager load the Orders collection, when you retrieve a Customer out of the database Entity Framework will generate SQL that retrieves both the Customer's information and the Customer's Orders in one query. However, if you choose to lazy load the Orders collection, when you retrieve a Customer out of the database Entity Framework will generate SQL that only pulls the Customer's information (Entity Framework will then generate a separate SQL statement if you access the Customer's Orders collection later in your code).
Determining when to use eager loading and when to use lazy loading all comes down to what you expect to do with the entities you retrieve. If you know you only need a Customer's information, then you should lazy-load the Orders collection (so that the SQL query can be efficient by only retrieving the Customer's information). Conversely, if you know you'll need to traverse through a Customer's Orders, then you should eager-load the Orders (so you'll save yourself an extra database hit once you access the Customer's Orders in your code).
P.S. Be very careful when using lazy-loading as it can lead to the N+1 problem. For example, let's say you have a page that displays a list of Customers and their Orders. However, you decide to use lazy-loading when fetching the Orders. When you iterate over the Customers collection, then over each Customer's Orders, you'll perform a database hit for each Customer to lazy-load in their Orders collection. This means that for N customers, you'll have N+1 database hits (1 database hit to load up all the Customers, then N database hits to load up each of their Orders) instead of just 1 database hit had you used eager loading (which would have retrieved all Customers and their Orders in one query).
If you come from SQL world think about JOIN.
If you have to show in a grid 10 orders and the customer that put the order you have 2 choices:
1) LAZY LOAD ( = 11 queryes = SLOW PERFORMANCES)
EF will shot a query to retrieve the orders and a query for each order to retrieve the customer data.
Select * from order where order=1
+
10 x (Select * from customer where id = (order.customerId))
1) EAGER LOAD ( = 1 query = HIGH PERFORMANCES)
EF will shot a single query to retrieve the orders and customers with a JOIN.
Select * from orders INNER JOIN customers on orders.customerId=customer.Id where order=1
PS:
When you retrieve an object from the db, the object is stored in a cache while the context is active.
In the example that I made with LAZY LOAD, if all the 10 orders relate to the same customer you will see only 2 query because when you ask to EF to retrieve an object the EF will check if the object is in the cache and if it find it will not fire another SQL query to the DB.
Eager loading is intended to solve the N+1 Selects problem endemic to ORMs. The short version is this: If you are going to directly retrieve some number of entities and you know you will be accessing certain related entities via the retrieved entities, it is much more efficient to retrieve all the related entities up-front in one pass, as compared to retrieving them incrementally via lazy loading.
An important issue is serialization. Microsoft recommends NOT using the default lazy loading if you're dealing with serialized objects. Serialization causes ALL related properties to be called, which can start a chain reaction of related entities being queried. This really comes into play if you're returning JSON data from a controller. JSON data is obviously serialized. You'd either want to return data immediately via Eager or turn the lazyloading off in the context and employ Explicit Lazy loading.
I have a database with a table for active orders and one for inactive orders. I would like to model this in Entity Framework as one entity called Orders. I also need a way to determine if an order in this collection is active or not, preferably by having a status property on the entity that is set according to what table it is in. Is there anyway to do this using Entity Framework 1. What about in Entity Framework 4?
You could create a view in your DB and generate the entity from that.
Take a look at the Table Per Concrete Type inheritance.
It is described here in ADO.NET Team Blog.
I think this is what you are looking for: How to: Define a Model with Multiple Entity Sets per Type (Entity Framework)
"The Entity Data Model (EDM) allows an entity type to be included by multiple entity sets within a single entity container or for an entity type to be included in entity sets in multiple entity containers. Defining multiple entity sets per type (MEST) allows users to streamline their code when databases have partitioning or other such scenarios where multiple tables have the same structure."
If I am understanding you correctly both active and inactive orders would share the same properties (for example: both would have a decimal "amount" property) if this is the case then in EF 1, I am pretty certain this is not possible. I think you will have to fall back to Mapping your entities to a POCO Orders object.
A good way to do one entity that shares multiple tables is to use Entity Splitting. MSDN has a very simple tutorial that walks you through the process which is very easy, however, you may need to reshape your data model: http://msdn.microsoft.com/en-us/data/jj715646.aspx