vt dotnet user group meeting

I went to my first Vermont .NET Users Group meeting last night, which was pretty interesting.  Julia Lerman, who leads the group, gave a presentation on the .NET Entity Framework, which she just finished a book about.  My boss says he’s heard that there are many Microsoft MVPs who are pretty against the EF, because it has many of the usual problems that accompany the first release of something big.  But after listening to Julia last night, it sounds like something that many of us in the .NET world will be using sooner or later.

One of the main interesting things was the fact that apparently there’s been a split between the people who created the LINQ to SQL stuff and the Entity Framework people.  They do similar things, and yet Microsoft hasn’t addressed the difference between them until recently, where they revealed that “the Entity Framework will be our recommended data access solution for LINQ to relational scenarios.”

That is why I don’t spend too much time learning Microsoft technologies until they are out of beta.  Half the time, the effort expended to learn their latest and greatest is wasted!

Click the link to read my meeting notes…

two worlds: the data store looks nothing like the business domain.  you spend a bunch of time writing code that goes back and forth between the two.

EF is more than an ORM tool.  it helps you not have to worry about how to get in and out of the db.  or if you want to change the obj model you don’t have to worry about the db access.  you work with the object model right in the app, and you don’t have to worry about the db…”y’know – kinda – right?”

MS calls the data model in the app the “Entity Data Model”.  IT’s not the same as the EF.  the EDM is an idea, and it uses the EF to work with the app.

There’s an impressive slide that says MS is going to be integrating the EDM into lots of products, SQL08, Office, BizTalk, etc.

In .NET3.5, you can use DataSets, linq to sql, and the entity framework.  linq to sql came out of the language teams.  but they didn’t really talk to the data access teams, who had been working on the EF for years.  linq is just a query language.  the EF people built a linq to entities framework.

the data access people took over linq to sql, and so after pdc this year the data access people said that linq to sql is going to lose some focus in favor of entity framework, in an ado.net team blog posting.  julie says she thinks of linq to sql as entity frameowrk lite.  there’ll be a migration path.  but it’s worth focusing more on EF if you’re not heavily invested in linq to sql.

three layers of metadata: EDM, a conceptual model of the data, as reports, objects, services, a storage model of db objects schema, and a map between the two.  *.csdl = EDM, *.ssdl = schema, *.msl = map

providers for other databases

for querying, you can use “linq to entities” (strongly typed, used against code-gen’d classes), as well as “entity sql” (text-based, sql-like, dynamic, and goes against the model).

L-To-E:
from c in context.Customers
where c.ORders.Any()
select c, c.Orders

E-SQL:
“select c, c.Orders
from model.Customers
where ” + var1 +
” and ” + var2

they created e-sql first, but then linq was invented and it seemed like it would be cool to use as well.  l-to-e actually depends on the ef apis to do their work.

ef will keep track of changes to an entity object.  datasets can keep track of their changes because the objects themselves have the changes, the new and old values.  but ef objects only have their current values, and there’s another part of the ef that keeps track of changes.  once you move ef objects across processes, the framework is not able to keep track of the changes.  so in a distributed environment it all falls apart.  this is the main problem that is keeping people from adopting this till the next version.  julie has made a stink about it and there’s a section of her book about how to deal with it.  it’s possible to deal with it in v1, but it’s just a pain in the ass.

there’s a new project called Oslo that is really important, don box, chris sells, someone vicks is all working on it.  modeling your application.  modeling in general is really important for ms.  the next v of ef is with studio2010.

you can use business logic with ef.  you can extend them with partial classes, custom interfaces, inherit from EntityObject, or implement IPOCO interfaces (Plain Old CLR Objects).  POCO is not supported in v1.

part2 – you can do *that*??

foreign key problems:
example of customer -> order relationship.  one to many.  in the db the orders table would show a customerid, but in ef, it’s shown as an object relationship, a “navigation property”, a customer object.  for relationships that refer to single objects and not collections, it creates an additional property called ObjectReference.  so in our example, the entity obj would have a customer property and a customerreference property.

assign a reference without a trip to the db:
problem: have foreign key value but not the instantiated value but not the instantiated entity for an Entity Reference.
solution: set the reference using an EntityKey rather than an object instance.
when you are using an entity, it only gets the object you ask for.  if you get a customer entity, it won’t get the customer type, for example.  (which makes sense – if it was going through to fetch all the relationships, it’d pull back the whole database).

Leave a Reply