I recently recorded a couple of dnrTV episodes which give some basic introduction to parts of the Entity Framework. It's my hope that these will help people quickly get some ideas about what the EF can do and how to get started using it. The first episode is up now at: http://www.dnrtv.com/default.aspx?showNum=117
Check it out and let me know what you think.
- Danny
We had some family come in from out of state for a visit this week, so we decided to see how much of the sights in and around the Seattle area we could cram into a few days. My wife, her mom and her cousin together took over 1100 pictures in 3 days as we visited some pretty amazing places. As I was consolidating all the digital photos on a few DVDs for everyone to share I was struck by the colors and the beauty of this place where I'm so fortunate to live. So I thought I'd share a few with all of you.
We started with a trip up to Hurricane Ridge which is just south of Port Angeles and at the very North end of Olympic National Park:
Next we took a short hike through the woods to Marymere Falls and along the way we had to stop and try to capture the size of some of the giant trees -- four cousins joining hands couldn't quite reach halfway around this one:
We ended our first day with a stop at Salt Creek Recreation area where we hoped to visit some awesome tide pools on the shore of the Straight of Juan de Fuca. Unfortunately we had bad information about the timing of the tides so we arrived right at high tide rather than low tide. Not that big a loss, though, because the sunset was awesome:
The next day we got up, took two ferries to Friday Harbor on the San Juan Islands and went out whale watching. We saw many Orcas:
For our third day we returned to Seattle proper to visit the Pike Place Market...
and while seeing guys throw huge salmon is cool, we were struck by the beauty of the produce:
We finished our time by letting the kids play in the International Fountain at the Seattle Center:
In the immortal words of Ferris Bueller, "Life moves pretty fast. If you don't stop and look around once in a while, you could miss it." And who would want to miss all of this? Here's hoping those of you in the northern hemisphere are having a good summer and that all of you get a chance to stop and look around sometime soon. :-)
- Danny
|
Julie Lerman called me out to participate in this set of questions about how folks got started programming, and it is fun to hear about those kinds of things. So here are my answers and at the bottom a few more people I’ll add to the process.
How old were you when you first started programming?
I think my first experiments with programming happened when I was 9 or 10 on the TRS-80 Model 1 or Model 3 of some friends at school, but I really began programming when I was given my first computer, an Apple ][+, at age 11.
How did you get started in programming?
I remember staying up late on Christmas day writing a program that experimented with getting input from the user, for loops and adding attributes to things to make them flash and such. From that very first day with my own computer I was hooked. For a long time, though, I thought computers would just be a side-line for me and that I would focus on some other field—probably my most common answer to the “what do you want to be when you grow up” question was that I wanted to double major in mechanical and electrical engineering and focus on robotics. As I got older, though, I realized that programming was really the thing that got me excited.
What was your first language?
I programmed initially in applesoft basic (both programs of my own and ones that I typed in from the back of magazines or books), but it didn’t take me long to start experimenting with 6502 assembler, and it was really cool when I got the “Microsoft language card” for my apple (which was really just a 16k ram card taking the machine up from 48k to 64k) because then I could start programming in Pascal. On a side note, this Pascal implementation was actually a very early version of something like managed code because the compiler output p-code which was interpreted at runtime (something like IL or java bytecodes).
What was the first real program you wrote?
What I remember of the very first program I wrote (mentioned above) is something about a count down and an explosion which was the whole screen in flashing type. After that I know there were many other programs but the next significant thing I remember was being paid some trivial amount by an older student at my school who wanted a program which would simulate large D&D battles involving many players without him having to roll the dice by hand. Later I remember really pushing the envelope of my apple by writing programs that did animation of a 3-d wireframe model of the space shuttle with hidden lines removed.
What languages have you used since you started programming?
I went through a phase in college where I was fascinated by the idea of exploring every programming language I could get my hands on, and I dabbled with many things from forth to prolog to modula-2, etc., but I never wrote enough code in any of those to really claim that I’ve used them. A more realistic list would look something like this: basic (*several* flavors), pascal, 6502, 80X86 and 68000 assembler, informix-4gl, clipper, c, c++, scheme, elisp, perl, tcl, vb, c#.
What was your first professional programming gig?
Toward the end of my senior year in high school I took a job working for a local title company doing some computer training and other miscellaneous tasks. Somehow I talked my way into turning it (for a while at least) into a programming job creating a computer-assisted learning program. Since programming wasn’t really the original intent of that job, though, I probably have to point to my second computer gig as the first real job where programming was part of what was expected. I was working at a small computer store doing a combination of sales and service/technical support. My first real programming job was something that one of the owners volunteered us for: creating a database system using Informix to help a charitable organization which was creating a park with a fountain and for a donation you could purchase a brick, have it inscribed and then they would place it in the park. The system I wrote tracked the inscriptions and created files which were sent to the engraving company.
If you knew then what you know now, would you have started programming?
Absolutely! The joy of creating software, working with teams of exceedingly smart people, constantly learning and doing things that can really change the way people work, live and play is something I’m very thankful for.
If there is one thing you learned along the way that you would tell new developers, what would it be?
Building great software is so much more than just getting the computer to run—don’t forget that at its heart this endeavor is all about people, so make sure you focus not just on the technical stuff but also on what we sometimes call the “soft skills” especially all forms of communication.
What's the most fun you've ever had ... programming?
The most fun I’ve had programming has always been working on a project with one or two really smart people when the ideas are flying and we’re pushing the envelope of what we think are brains are capable of. There’s nothing quite like that mindbender where you come across a concept that completely challenges the way you think which leads to a whole series of “Ah ha!” moments as you capture parts of it—often only to discover that there are more depths than you realized so you know you’ll need another “Ah ha!” before you are done. I shared some of the best of these moments with my good friend and partner in crime from high school, Mike. These days I most often get to share the feeling vicariously with my son, Keith, who is just about to turn 13 and is rapidly becoming a much more sophisticated programmer than I ever was at that age.
Who’s next?
Well, I don’t know if we’ll be able to coax them all into responding or not, but I’m always up for an opportunity to learn more about the folks I work with. So I’ll add 5 of my colleagues to the list.
|
Just a quick note to make sure people are aware of a couple interesting events from the last day or two.
First, one of my colleagues, Jarek, posted our Sample Oracle Provider for the EF. I should stress that this is a sample not an official supported Oracle provider from Microsoft, but it is designed to help provider writers learn more about building providers for the EF, as well as to highlight some of the particular challenges encountered in briding between the EF's view of the world and that of Oracle, to fully demonstrate the provider-agnostic nature of the EF, etc.
Secondly, I'm excited to let you know that today we launched the new EF transparent design process. Over the last year or two as we were building the first version of the EF, we were fortunate to have a lot of great feedback from folks both inside and outside of Microsoft, and within the constraints of a large, logistically challenging first release, we did our best to react to that feedback and made a number of changes--some of which have seen the light of day in v1 and some which have begun but won't complete until v2 or later. It has become very clear, however, that we need to do a lot more to gather that feedback earlier in the process and improve our ability to react to it. One of the first steps in that direction was the creation of the advisory council. It's my hope that the new design process will be a further positive move along that path. As more details emerge, please let us know what you think.
- Danny
As we wrap up VS 2008/.Net 3.5 SP1 and begin planning in earnest for the next release, we’ve been brainstorming various ways to improve our understanding of the problem space and to create feedback channels for our plans. I appreciate the feedback that many of you have already given about the Entity Framework, LINQ to SQL, ADO.Net Data Services and other aspects of the Data Programmability team’s efforts. One recurring theme in that feedback has been around domain driven design, so among our other criteria we’ve put together an advisory council which includes some members with notable credentials in that area.
I’m excited to announce that the council, which will have its first meeting in July, will include:
Eric Evans - http://www.domainlanguage.com/about/ericevans.html
Stephen Forte - http://www.stephenforte.net/
Martin Fowler - http://martinfowler.com/
Pavel Hruby - http://www.phruby.com/
Jimmy Nilsson - http://jimmynilsson.com/
…as well as additional folks from various teams in Microsoft.
While I’m optimistic that these folks will provide great feedback, I also want to encourage all of you to continue sharing your thoughts. I can’t tell you how much that means to me.
- Danny
There are a number of places where you can read an introduction to the Entity Framework, listen to a podcast about it, or watch a screen cast or video of an interview. Even with these various resources, though, there are so many different data access technologies out there that it's not uncommon for me to get the question: Why should I use the Entity Framework? Or what differentiates it from other options like just using ADO.Net SqlClient and friends, LINQ to SQL or something like nHibernate? I like the second question better, because the truth is that different problems merit different solutions. So here's just a quick take on my perspective about these:
Entity Framework vs. traditional ADO.Net
All of the standard ORM arguments apply here. The highlights are that you can write code against the Entity Framework and the system will automatically produce objects for you as well as track changes on those objects and simplify the process of updating the database. The EF can therefore replace a large chunk of code you would otherwise have to write and maintain yourself. Further, because the mapping between your objects and your database is specified declaratively instead of in code, if you need to change your database schema, you can minimize the impact on the code you have to modify in your applications--so the system provides a level of abstraction which helps isolate the app from the database. Finally, the queries and other operations you write into your code are specified in a syntax that is not specific to any particular database vendor--in ado.net prior to the EF, ado.net provided a common syntax for creating connections, executing queries and processing results, but there was no common language for the queries themselves; ado.net just passed a string from your program down to the provider without manipulating that string at all, and if you wanted to move an app from Oracle to SQL Server, you would have to change a number of the queries. With the EF, the queries are written in LINQ or Entity SQL and then translated at runtime by the providers to the particular back-end query syntax for that database.
Entity Framework vs. LINQ to SQL
The first big difference between the Entity Framework and LINQ to SQL is that the EF has a full provider model which means that as providers come online (and there are several in beta now and many which have committed to release within 3 months of the EF RTM), you will be able to use the EF against not only SQL Server and SQL CE but also Oracle, DB2, Informix, MySQL, Postgres, etc.
Next there is the fact that LINQ to SQL provides very limited mapping capabilities. For the most part L2S classes must be one-to-one with the database (with the exception of one form of inheritance where there is a single table for all of the entity types in a hierarchy and a discriminator column which indicates which type a particular row represents). In the case of the EF, there is a client-side view engine which can transform queries and updates made to the conceptual model into equivalent operations against the database. The mapping system will produce those views for a variety of transformations.
You can apply a variety of inheritance strategies: Assume you have an inheritance model with animal, dog:animal & cat:animal. You can not only do what L2S does and create a single table with all the properties from animal, dog & cat plus a column that indicates if a particular row is just a generic animal or a dog or a cat, but you can also have 3 tables where each table has all of the properties of that particular type (the dog table has not only dog-specific columns but also all the same columns as animal), or 3 tables such that the dog and cat tables have only the key plus those properties specific to their type of animal and retrieving a dog object would involve a join between the animal table and the dog table. And you can further combine these strategies so some parts of a hierarchy might live in one table and some parts in separate tables.
In addition you can do what we call "entity splitting" where a single type has properties which are drawn from two separate tables, and you can model complex types where there is a type which is nested within a larger entity and which doesn't have its own separate identity--it just groups some properties together. The best example of this is something like address where the street, city, state and zip properties go together logically, but they don't have independent identity. The address is only interesting as a set of properties that are part of a customer or whatever. As you have noticed, for v1 you can't create complex types with the designer in the EF--you have to code them by hand in the XML files.
Entity Framework vs. nHibernate
Because nHibernate is a rather full-featured ORM, the distinguishing features between the EF and it are not as large. In fact, it is certainly true that nHibernate is a more mature product and in many ways has more ORM features than the EF. The big difference between the EF and nHibernate is around the Entity Data Model (EDM) and the long-term vision for the data platform we are building around it. The EF was specifically structured to separate the process of mapping queries/shaping results from building objects and tracking changes. This makes it easier to create a conceptual model which is how you want to think about your data and then reuse that conceptual model for a number of other services besides just building objects. Long-term we are working to build EDM awareness into a variety of other Microsoft products so that if you have an Entity Data Model, you should be able to automatically create REST-oriented web services over that model (ADO.Net Data Services aka Astoria), write reports against that model (Reporting Services), synchronize data between a server and an offline client store where the data is moved atomically as entities even if those entities draw from multiple database tables on the server, create workflows from entity-aware building blocks, etc. etc. Not only does this increase the value of the data model by allowing it to be reused for many parts of your overall solution, but it also allows us to invest more heavily in common tools which will streamline the development process, make developer learning apply to more scenarios, etc. So the differentiator is not that the EF supports more flexible mapping than nHibernate or something like that, it's that the EF is not just an ORM--it's the first step in a much larger vision of an entity-aware data platform.
Just a quick note to point out a few interesting things about the updated version of the EF which shipped this week with the beta of VS 2008 / .Net 3.5 SP1:
- The initial announcement didn't include links to updated versions of the documentation or our samples, but you can now find the updated docs here (including docs for new things like the entity data source) and at least some of the samples here.
- I just made a pass through the EF FAQ updating things for SP1 Beta, etc. There's still a lot of work needed (please help), but I hope you will find this a useful resource.
- I highly encourage you to look over the post on the ado.net team blog for more info about what's new. There should also be a post listing breaking changes there very soon.
- Finally, let me highlight a couple of the more interesting new features for those of you who have been following my blog and things like my adventures with web services and EntityBag... This release of the EF works in conjunction with updates to WCF made in SP1 to enable out of the box serialization of entity graphs (including cycles). This will make creating web services that return graphs of entities brain-dead simple. It also deals with the known types problem so that inheritance works seemlessly with EF models and WCF services. So a couple of the issues I had to deal with in EntityBag are just solved for you out of the box.
What it doesn't do, though, is handle change tracking on the client and the like. These are still important topics which we'll work on addressing in v2 of the EF, but in the meantime, I'm going to try to put together an updated version of EntityBag which will work with the new EF bits. It's very likely, though, that this won't appear right away. There's just too many things to do not only around finishing up v1 but we're starting to think deeply about v2, etc.
- Danny
There's a lot going on today! Not only has VS 2008 SP1 Beta been released (with the EF fully integrated into setup and including a number of new features and bug fixes), but also Jarek Kowalski, who is a really smart colleague on the EF team, put up the first blog post in a series he has written which shows some exciting ways that you can layer some code on top of the EF and achieve lazy loading. The goals for his effort are pretty ambitious, and he has achieved them admirably. You might find this code very useful, and it's also a great sign of the flexibility of the EF. I'm so excited to see these kinds of things popping up both from folks inside Microsoft and those on the outside as well. This is how we translate the work of the EF team into real value for folks on many projects.
- Danny
I had so much fun talking with folks at DevConnections in Las Vegas last fall that I really wanted to attend a conference again this spring so I could share more about what we're doing with the Entity Framework and meet more great people who are interested in or even using the EF or LINQ to SQL. As it turns out, they needed someone to present a couple of sessions at the upcoming DevConnections in Orlando, so I signed up.
My two talks are:
VMD314: Entity Framework in the Real World
Daniel Simmons
Come see the Entity Framework in action! Check out an exciting new open source application built on the Entity Framework. During this session we’ll discuss and demo the use of the Entity Framework to build a LOB application in the healthcare vertical.
VDM215: Entity Framework: Application Patterns
Daniel Simmons
Microsoft is introducing the ADO.NET Entity Framework and the Entity Data Model to help developers code against first-class business objects when creating business applications. Like any new technology, most of the information available on the topic focuses on what the Entity Framework is, what are its constituting components and related aspects. This session takes the audience beyond the “what“ of the Entity Framework, instead delving into various application scenarios and approaches to application architecture to show how one can use the Entity Framework today. We shall discuss the role of Entity Framework in Web, rich-client, and service-oriented applications.
But I also plan to attend as many of the EF and L2S sessions as I possibly can, so if you are going to be there, I'd love to meet you. I'm usually pretty easy to find because a) I often carry around a bright, lime-green backpack, and b) when it comes to these topics I have an awful hard time keeping my mouth shut. ;-)
- Danny
Probably the most frequent question I get these days is, "by the way, when will the EF finally ship?" I can imagine how frustrating it must be not having more concrete data about this stuff, and sadly all we're able to tell you is that it will ship some time this summer. Unfortunately I don't have any new news on that front, but what I can (finally) share with you is the ship vehicle.
There will be an SP1 of VS 2008/.Net Framework 3.5, and the Entity Framework and its designer will ship with it. In fact, there will be a beta for SP1 coming out sometime soon with all of our bits nicely integrated with VS and the .Net Framework--no more install Orcas, then install this beta thing, then a patch, then another beta thing or whatever that song and dance was.
- Danny
Today in the forum a question came up that illuminates some non-obvious aspects of the EntityFramework which is pretty important so I wanted to copy some of my response here and expand a little to give it a bit more exposure.
The problem statement is essentially this: I have the entity key for something I want to delete, and I want to minimize round trips to the database so I fake up an entity object, set the key, attach it to the context, call DeleteObject and then call SaveChanges. Sounds great right? Unfortunately, in a number of cases SaveChanges will throw an exception at this point without even attempting to make a call to the database. To make things more confusing, the answer is to retrieve more info from the DB first (either through a query or by explicitly attaching). You might say, "So in order to delete something successfully I have to load more data? Huh? Why can't you just delete the record with the key I gave you and be done?"
The background is a bit interesting. What we are encountering here is the fact that the EF both allows you to describe some fairly high level semantics about your model and abstracts away the underlying physical representation of that model in the database. The place where this bites us is when I have required relationships for an entity. For example, I might have a model with customers and salespeople where the association is modeled such that ever customer must have a salesperson. With this kind of model, I might map this to the database as a foreign key column in the customer table which contains the id of the salesperson -- or -- I might model it as a separate link table which has customer ids and salesperson ids but just has a constraint that the customer id is unique (that way the same salesperson can appear many times saying that the salesperson has multiple customers, but the customer can only appear once and will specify which salesperson goes with that customer).
The way the EF deals with the fact that either database schema is valid with this model (just with different mappings) is that it reasons about entities and relationships largely independently of one another. When it comes time to save changes, the EF looks over the ObjectStateManager to find the operations it must map to and carry out on the database and then it goes through a validation phase to make sure that the operations will make sense and result in a coherent final database state. So if you have an entry in the state manager saying that an entity should be deleted, then the EF will look at your model to determine if there are any required relationships. If the model says that there are (because for instance, deleting a customer means you must also delete the relationship between that customer and their salesperson), then the EF will make sure that the state manager also has an entry indicating the relationship that should be deleted. If that entry doesn't exist, then the SaveChanges operation will fail. If it didn't know about the relationships and didn't make this validation step, then the EF could try to delete the row in the customer table without deleting the corresponding row in the link table if your database schema worked that way which would cause even less clear exceptions to flow up from the database. With the relationship info, the EF can delete things from both tables automatically if necessary.
Given this relatively non-intuitive requirement, the EF goes to some lengths to make most scenarios handle this automatically. In particular, when you retrieve entities via a query, the query is automatically rewritten to bring along relationship info (a feature we internally call "relationship span"). That way the state manager will be aware of those relationships, and if you indicate that an entity should be deleted, then the relationships are marked deleted as well, and the EF has all the info it needs to delete things.
In the event that you attach things, though, you must supply all the needed info. This can be done either by querying for the entity you want to delete using its key, or it can be done by setting the key of required relationships on the EntityReference's EntityKey property. In our example this would be the key of the salesperson. If you set that property and then attach the customer, the attach operation will automatically create the relationship entry as well as the entry for the customer entity.
For more information about relationship span, you might want to check out this previous blog post: http://blogs.msdn.com/dsimmons/archive/2007/12/21/filtered-association-loading-and-re-creating-an-entity-graph-across-a-web-service-boundary.aspx
- Danny
In my ongoing series of trying to repurpose / further broadcast important topics that come up in the forum, I thought folks might be interested in the discussion going on in this thread. A key part of this discussion is coming back to this question of ObjectContext lifetime that I discussed in this previous post.
Of course there's more than one way to do things, and Rick Strahl made a comment to that post pushing back on the idea of keeping a context around for an extended period of time because of concerns over things like building up an overall set of changes and then deciding that you want to "undo" part of those changes but not all of them before saving, etc. One approach he suggests is using a separate context per business object. The problems here, though, are around things like relationships which need to be tracked and modified somewhere. Yes, you can do this, and in some situations it may be better, but it certainly brings along its own complexity when it comes to managing all these contexts and context lifetimes.
For many scenarios I recommend using a single context (or one per thread if your app is multi-threaded). When it comes to these partial undo kinds of scenarios, I admit that there is some extra complexity--in fact there was some discussion on the team just in the last couple of days about looking into a number of related scenarios as we do planning for v2 which may lead to some additional features which will help here (how about a "RejectChanges" method which could be used to undo changes to an entity and its relationships without throwing out the whole context, for instance). Often times, though, those kinds of concerns can also be addressed by reducing the granularity of your units of work to the point where you can either commit an entire set of changes in the context or throw it out.
Taking this kind of approach allows you to sort of "go with the flow of the EF" which brings me back to the forum thread that started this post. In that thread, there's discussion about what belongs in what layer of the app--should you explicitly write a layer that hides all data access like we used to do? For most cases I would suggest "no". Part of the idea of the Entity Framework is that *it* provides the abstraction which hides the database. I think about it like this:
UI Layer / Top-level Application coordination
This is code which may reference lower layers but doesn't contain any EF framework code at all.
-----------------
Business Objects layer
These are your entities -- some of this code may be generated by the EF tools, but it is augmented with your own code supplied in partial classes, partial methods, event handlers, etc.
------------------
Data Layer
This is largely code which the EF supplies. It abstracts your business objects away from the details of the database. In past you would have written this pretty much all by hand, and this would be the only code that really interacts directly with ado.net. In the EF paradigm, you might often allow code to interact with EF framework code which takes the place of some of what you would have written by hand in this layer. The ObjectContext largely represents this layer, and you can extend it with its partial class as well as various event handlers and such so that you can customize the experience here, but you just don't have to write as much yourself.
Of course there's nothing that says you can't write your own data layer which encapsulates the EF code that I described as the data layer, but for many applications I tend to think that will make your life harder for relatively little benefit. One of the main reasons we would write a completely separate data layer in the past is that we wanted to isolate the business logic from changes in database schema and the like. The EF now does that for you with its mapping layer.
- Danny
It was somewhat delayed, but a CTP of SQL Compact Edition with support for the EF that works with beta 3 is now available. You can download it from:
http://www.microsoft.com/downloads/details.aspx?FamilyID=68539FAE-CF03-4C3B-AEDA-769CC205FE5F&displaylang=en
