Rants Tagged with “Entity Framework”
1 2 > >> (Total Pages: 2/Total Results: 13)
UPDATE: Roger Jennings correctly stated, I meant to say that Include is *not* a guarantee.
When I am using the Entity Framework for a project, I have gotten into the habit of using eager loading via the Include syntax. In case you're not familiar it, the Entity Framework has a different philosophy than other data layers (e.g. NHibernate). In the Entity Framework, relationships have to be manually loaded when they are lazy loaded (so developers never have network round-trips without explicitly knowing about it). Whether you agree or not with this philosophy, understanding how it works is helpful when you're working with the Entity Framework.
The Entity Framework supports eager loading of the data as well using the Include syntax. For example:
var qry = from w in ctx.Workshops.Include("Topic")
orderby w.Name
select w;
By amending the source of the query with the Include method, you can eager load relationships. The problem is that these are really hints to the Entity Framework to load the relationships, but not a guarantee. Depending on the query, these Includes may be dropped. The two scenarios I see this most often are the grouping and subselects:
// Drops the Include
var qry = from e in ctx.Events
.Include("Workshop")
where e.EventDate >= DateTime.Today
group e by e.EventLocation.Region into r
select r;
I ran into a good post on the forums on the subject:
In that post, Diego Vega says that Include only makes sense in the following scenarios:
- Include only applies to items in the query results: objects that are projected at the outermost operation in the query, for instance, the last Select() operation (in your query, you tried to apply Include to a subquery)
- The type of the results has to be an entity type (not the case in your query)
- The query cannot contain operations that change the type of the result between Include and the outermost operation (i.e. a GroupBy() or a Select() operation that changes the result type)
- The parameter taken by Include is a dot-delimited path of navigation properties that have to be navigable from an instance of the type returned at the outermost operation
To alleviate the problem in some scenarios, you can use the EFExtensions Include Extension method to add includes on the complete query like so:
using Microsoft.Data.Extensions;
// ...
var qry = from e in ctx.Events
where e.EventDate >= DateTime.Today
select e;
List results = qry.Include("Workshop").ToList();
You can find the EFExtensions at the MSDN Code site here:
Has this bitten you before?
I've finally had a chance to update my Silverlight 2-ADO.NET Data Services example. In this new sample I show how to create a Line-of-Business application (an XBox Game editor) using ADO.NET Data Services against both an Entity Framework model and NHibernate. Unlike earlier examples, this one includes implementation against the ADO.NET Data Service Silverlight 2 library to support saving of changed entities. In addition, I show some techniques for paging, retrieving simple types over an ADO.NET Data Service and full styling of the application. I hope to add support for Forms Authentication in the coming weeks.
Feel free to post replies with questions about the sample.
Data is a funny business. While at the moment I am spending a lot of time teaching Silverlight, my passion still lives in the data. I was brought up on Minisystems (Multi-user CP/M and the like) where you were dealing with something like a database (though we didn't have that as firm a concept as you might think). Later I did quite a lot of desktop database development starting with dBase II (yes, I am that old), Paradox, Clipper, FoxPro and even Access. That naturally led to client-server and N-Tier development. Throughout all the time its become exceptionally clear how much data matters to most applications.
But using databases can be difficult as there is an impedance mismatch with object-oriented development and the natural structure of data. The solution to this for many organizations has been to build data access and business object layers around the data. These layers were meant to simplify data access for most developers and embed the business logic directly into a re-usable set of code instead of it ending up in the UI layer. This was a good thing...
But the problem is that much of the data access (and to a lesser extent, business object) code was very redundant. Developers ended up writing the same code or simply mimicking schema that was in the database. Some started to develop ways to use the database schema to their advantage to limit the amount of hand-written code was created. While not always called this, this is where object-relational mapping (ORM) products got their start.
ORM is a good thing. But ORM is about data access, not business rules. Its a important distinction that needs to be understood. ORM's typically were bad at defining and managing business rules, but that was never their job. Keep this in mind when you think about ORM and Business Objects (or just read Rocky Lhotka's book on the subject).
Now that ORM's have become a staple of data access, we have a ecosystem where there are a huge number of competing products (1st party, 3rd party and open source). The most common question I get these days when I meet people at user groups or conferences is "What ORM should I use for my new project?" This question is flawed. The problem with this question is that there is not a singular solution for data access (ORM et al.) that solve all problems. In fact there are many solutions to this problem that fit the needs to particular use cases. So when I get this question, I attempt to ask more questions but in reality this isn't a question that can be answered on the back of a napkin.
The recent brouhaha about the Entity Framework is a great example of this problem. Many of the complaints about the Entity Framework (or any ORM really) are central to the viewer's point of view. This is true of NHibernate as well. Its great in the right environment, but lousy in others. I wish I could encourage the community to stop trying to find the perfect ORM. It doesn't exist. Its like the perfect car, perfect beer or perfect woman. The perfect car for speeding on a racetrack is horrible for taking the kids to hockey practice.
Why do I think this is true? Because I tried to write it. Several years ago I was fed up with the ORM landscape and decided that I would try to write one that fixed the flaws of all the other solutions. I spent nearly four months part time tinkering with the code to get it working the way I wanted it to. But I kept finding myself backed into corners. "If I implement it this way, its great for X, but lousy for Y." I finally decided that all ORM's are flawed because the problem is inherently driven by a core set of requirements. No tool could possibly meet the criteria of every project.
Picking a data access strategy involves more than just functional requirements. Its not about the size of the project, the speed of the runtime environment or even the veracity of the tools. Its bigger than that. Though this list is incomplete, when I talk to people about this problem I encourage them to look at the requirements of their project to include (but not limited to):
- Functional Requirements
- System Requirements
- Skill-set of the Development Team
- Business Factors
- Time-to-Market
- Business Culture
- Lifetime of Project
- Volatility of Schema
I could go on, but I think you can fill this out with lots more. The situation is that ORM's that are good for certain environments are bad for others. For example, if I were writing a website for a mom-n-pop Pizza Parlour in my neighborhood, if I had to have data, I'd likely pick something like "LINQ to SQL" as it is always going to be directly mapped to tables and the size of their database and throughput are low. Getting the job done on budget is more important than worrying about performance or refactor-ability.
In contrast, if I was building a large financial system where concurrent transactions and high volume processing was critical to the project's success, I'd likely hand-code or use something like NHibernate. Spending more time on hand coding for performance pays off on a big, high-volume project like this but would be wasted on the other project.
Lastly, if I were to be remotely working on a small project with a team who are not that well versed in database development, I might pick something that did a lot of the code generation for me (like LLBLGenPro) where the developers could get up to speed quickly without having to understand the basics of database development.
Some times its specific philosophies that help find the right match. For example, if persistence ignorance and implicit data loading is important to your team, then a technology like NHibernate makes a lot of sense. But NHibernate often comes with the higher cost of object tracking (e.g. often you'll consume 2x memory with NHibernate since they are keeping the old and new objects to do comparisons).
Other example is the difference in philosophy of data access. One of the driving ideas in Entity Framework is the idea that a developer should never make a request to the database the they don't know about. This is very different from the idea in NHibernate that requesting a related object should *just work*. That's why understanding your team, your culture and your project all come together to help you find the right solution.
Please don't take my mentioning of specific technologies as specific preference but instead understand that picking a tool requires more than trivial review (e.g. (Its included in Visual Studio for free so we should use it.") Ultimately most projects spend more time tuning and tweaking their data access than building it so picking the right tool that gives you enough control is key to success. Don't get blinded by shiny designers, its ultimately the code that is more important.
I welcome your experiences and opinions...
The Entity Framework "No Confidence Vote" is a couple of days old now. I wanted to give the Internet a couple of days to chew it over and figure out where it really fit into the big picture. If you follow me on Twitter you may have seen some back and forth between Scott Belware and I recently. Most of this back and forth has been about his attacks of the Microsoft community (attacks of the technology or even the company are fair game as far as I am concerned). Getting personal by accusing me, the Microsoft community or even individual EF Team member's directly seems petty and unnecessary.
In that same light, some of the ALT.NET community (I won't name names) have accused me of being a shill for Microsoft's techologies. Anyone who has ever seen me talk about any Microsoft technology already knows that I pride myself in my centrist view of any technology (Microsoft's or others).
For me the power of the Entity Framework is *not* in its use as a ORM. There are dozens if not hundreds of ORMs out there. Depending on your specific use case, some are great...some are less than great. None is a perfect ORM for every case. My attitude about the Entity Framework is that it isn't a great ORM...but that it isn't trying to be. The power of the Entity Framework is in a common language for communicating a model. The Entity Data Model can handle complex scenarios. The big advantage in using the Entity Framework comes when the Entity Data Model is used by Microsoft and external projects. The effort required in building a real model of existing enterprise data is not trivial. The labor involved can only be recouped if the model is useful in other scenarios as a model of your data throughout your organization. That's not the case yet. Microsoft isn't there. In addition, the Entity Framework is not a good tool for the top-down development that Domain Driven Design and Model Driven Design are espousing. Again, I don't think that was ever their intention. But its important to know. There are other criticisms of the technology to me made but that's not the purpose of this post. Instead its to say that its a great start on a long-term strategy and for many people now isn't yet the time to use the Entity Framework.
But that being said, what is my opinion the No Confidence Vote? I don't think the technology should be killed. I think its a great start but still flawed as many v1 technologies are. My chief complaint with the whole movement in trying to kill the Entity Framework is the tone of the message. Angry bitter attacks on Microsoft and the Microsoft community do not help create dialog. It just creates division and a dug-in mentality. My experience is that if you attack a side, they are unlikely to change their minds but instead will just becoming more resistence to listening. Maybe that's the point. If you create an environment where Microsoft fails, then maybe nHibernate will get more traction.
So what do I think of nHibernate specifically (as it is the elephant in the living room that no one wants to mention)? Its a great framework. Period. I use it and have used and recommended it with past clients. I will continue to recommend it (and actually recommended it as well as other ORM's in a recent user group talk in defference to the Entity Framework in the v1 timeframe). So why do I care about the Entity Framework if I like nHibernate? Because they meet different goals. nHibernate is a persistence framework (or a ORM if you prefer). But it doesn't attempt or do a very good job of sharing its model across non-code environments (reporting, BI, etc.) And it shouldn't. Its not its job.
If I had one complaint with nHibernate it is in the realm of tooling. CodeSmith and MyGeneration templates are fine but they typically only do a object-to-table mapping. Everything else requries that you hand-code the XML. I think nHibernate design tools is where much of the effort for the project should be focused. That's why so many Microsoft developers have latched onto LINQ for SQL and Entity Framework. Its confortable for them to build models visually.
One last note, of the personal attacks I wanted to point out one person who is taking way too much shrapnel: Julia Lerman. I've known Julia for a number of years and I think she is exceptionally talented and very well intentioned. Picking on her because of her visibility in the Entity Framework is shameful. I have never known her to not talk about the warts as well as the benefits and I expect her forthcoming book will do the same. The real shame of this personal attack is that after many years in the community, she has taken on her first book. Writing your first book is a particularly vulnerable time for anyone. Having to weather the hostility towards the Entity Framework when she is just writing about the technology, not taking ownership in its authorship is a tough thing to do. I expect she'll come out the other side fine but it doesn't seem fair to deal with both at the same time.
I've known Julie Lerman (or is it Julia these days ;) for a long time now. She's an excellent resource for everything data related. In particular she's been keeping up with the Entity Framework and ADO.NET Data Services (formerly Astoria) updates in .NET 3.5 and VS SP1 Beta that was just released this week. If you are upgrading projects (like I am), she has two excellent blog posts about how to upgrade your projects:
New Entity Framework Changes
New ADO.NET Data Services (Astoria) Changes
Over the past week there have been a flurry of new projects coming out of Microsoft, mostly in the form of CTP's. I've been downloading like crazy and will likely be discussing my experience with them in the coming week. In case you missed any of them:
I expect that with the release of the EF Beta 3 means Astoria is coming soon. I'll let you know when it drops! Time to start digging in.
Come see me and Glen Gordon talk at Phipps Plaza in Atlanta about Visual Studio 2008, "Astoria", Entity Framework and Silverlight...and see them working gracefully together!
Click here to register for the event before it fills up.
Danny Simmons digs into some of the confusion about the different ways to handle persistence ignorance in the
Entity Framework. While I understand the attempt to fit in with the DDD guys and in some ways compete with NHibernate, I like that the persistence story isn't coddling to one side or the other...so you can have smart or stupid objects...your choice. Its worth a read if you want to see where this is going (and how its the polar opposite of the
LINQ to
SQL story).
I've been digging into the latest version of the Entity Framework Beta (and designer CTP) that dropped a few days ago. I've concocted a small example that shows the derivation model in the Entity Framework. Essentially it is a small model that has a Product type and two types that derive from that: ActiveProduct and DiscontinuedProduct:
Figure 1: Simple Model
The new design tools are pretty basic but interesting nonetheless. They seem to be modeled after the LINQ designer (which doesn't make me excited). The designer has a surface to draw types (or they can be created from database metadata) and create relationships between types (as seen in figure 1 above). In addition, there are two information panes: Entity Model Browser and Entity Mapping Details:
Figure 2: The complete Designer Experience (Click image for full size)
The idea of this simple model is to show how you can specify derived types in the designer. The derivation in our case evolves around the Discontinued field in the Products table in the Northwind database. The way that different types are typed in the model is using Conditions. In our case we are typing the database data as a Product if the Discontinued field is NULL (which should never happen really, but the designer doesn't seem to support the notion of an abstract type yet); if the Discontinued field is true (or 1) then its a DiscontinuedProduct type; and if the Discontinued field is false (or 0) then its an ActiveProduct. You can see these mapped in the Entity Mapping Details below:
Figure 3: ActiveProduct Mapping
Figure 4: DiscontinuedProduct Mapping
Once we have the model defined, we can use Object Services to query our data based on type (I could have used LINQ but I think the Entity SQL is clearer in this case):
-- Returns all Products
SELECT VALUE p
FROM NWEntities.Products as p
-- Returns only DiscontinuedProducts
SELECT VALUE p
FROM NWEntities.Products as p
WHERE p IS OF(NWModel.DiscontinuedProduct)
-- Returns only ActiveProducts
SELECT VALUE p
FROM NWEntities.Products as p
WHERE p IS OF(NWModel.ActiveProduct)
Feel free to download the demo (it only works if you have Orcas Beta 2 and the Entity Framework bits installed) and let me know what you think.
The ADO.NET team has been working hard on a new release of the Entity Framework with a boatload of new features (I haven't played with it yet, probalby this weekend). I know they are under some pressure as the June CTP shipped on July 2nd. Check it out if you want to see where they are going.
Caveat, it only works with a June CTP of VS 2008 Expression Web Edition. Not the Orcas Beta 1 or any other edition. I hope they release a VPC soon but I am not holding my breath waiting.
