Microsoft ADO.NET Entity Framework 4.1 Released | Hacker News Reader

Microsoft ADO.NET Entity Framework 4.1 Released

blogs.msdn.com

17 pointshanifvirani15 comments

One problem with Entity Framework is lack of alternative (not MS Sql Server) database support.

We are a Microsoft shop. However recently we've had to integrate with Oracle and now MySql. Oracle has just released beta support for EF: http://www.oracle.com/technetwork/topics/dotnet/downloads/or...

We have been Using Cool Storage (http://viciproject.com/wiki/projects/coolstorage/home) for quite some time. Honestly, It's the best ORM I've ever used. It stays out of your way and it doesn't surprise you. It's very easy to set up.

I'm surprised it hasn't gained more popularity. Cool Storage is the reason I haven't kept up on EF and the changes to ADO.NET. Bonus: it works with Oracle and other non MSFT databases. Bonus++: It's open source.

Very, uh, cool. I'll have to check out Cool Storage. How does it handle eager loading One-to-Many relationships? Such as, an Order has multiple Products and my query selects 3 Orders for a customer. Will those Products come pre-populated? A big issue I have with LinqToSQL and EF is the double/triple/n db dipping that can occur when trying to fill a complex entity.

I believe by default they are all loaded in one step. You can use the [Lazy] attribute if you want to lazy load instead.

A new release is coming soon: CoolStorage 1.5 will be released sometime in April and it will support the following platforms out of the box:

- .NET 3.5 / SQL Server

- .NET 3.5/ Oracle

- .NET 3.5 / MySql

- .NET 3.5 / Sqlite

- .NET 3.5 / MS Acess

- .NET 3.5 / VistaDB

- MonoTouch / Sqlite

- MonoDroid / Sqlite

- Windows Phone 7 / Sqlite

- Mono / Sqlite

http://forum.viciproject.com/viewtopic.php?f=8&t=368

(Disclaimer: MS Employee) - this release is actually pretty cool; you can create your models as regular classes and collections (with a very small number of annotations), and EF will create a schema on-the-fly, and new up MS's version of a Sqlite3 database as soon as the first request comes in.

Really great for F/OSS web projects on the MS stack since you don't have to perform the completely asinine step #1 of contributing, "Set up a SQL Express instance..."

First, let me say that I'm a fan of EF and .Net. In fact, our startup is running on C# and Azure right now. But all this talk of writing code and models and then having it create the schema drives me nuts and the normalization nazi in me dies a little bit. In what scenario other than your toy weekend project would you ever seriously use such a feature? No DBA is going to run with that. The DBAs at my past jobs still aren't even letting the developers do dynamic queries using LINQ (all db calls must go through a proc), let alone make a freaking schema.

Disclaimer: I have a good friend on the EF team and question almost everything they do :)

I suggest you lookup "domain driven design" and read some of the writings of people such as one of the guys behind NHibernate[1].

Some projects prefer to work in the OO domain, and treat persistence as something that should just be taken care of. DBAs don't always exist or have the final say. Then on the other end, you have things you describe, where the DBA defines everything related to the database, and that's that.

1: http://ayende.com/blog/default.aspx

I'm familiar with evil that is "domain driven design". I kid. But, I do start to worry when we try to treat SQL as something basically like NoSQL with JOIN support. Perhaps I don't full understand the flexibility in the features. But, I imagine you're going to run into a scenario where your object model spits out some pretty garbage schemas. Like I mentioned, we're using Azure and use their NoSQL'ish Table Storage for a lot of non-relational data so I feel I understand the advantages of just letting something 'take care' of storing something.

This would be the ideal situation. Unfortunately many of us are stuck with an existing schema or a schema from a third party databases with which we must integrate.

The domain driven design seems to work great for the brand new RoR apps. I enjoyed those when I did them b/c there was no crufty legacy schema.

I'd be curious to know how much code is written against legacy schemata versus green field development.

If you write your queries by hand using SQL and ADO.NET, you'll get, on average, about thirty less queries per transaction than you will using NH, but there's a reason CREATE/READ/UPDATE/DELETE spells CRUD. Writing all that SQL is a pain. Plus having the schema generated automatically is nice.

As an alternative to a full blown framework, I'd go with a simple object mapper, like

http://code.google.com/p/dapper-dot-net/

Not trying to bash the work that the EF team has done, but with things like not having enum support, which is something I view as so simple and trivial (even Linq-to-SQL does it), it makes the entire thing seem not so serious.

Agreed, the lack of enum support drives me nuts. Hell I wrote an ORM in the .Net 1.1 days that had it.

Still I'm glad they've released this, more "out of band" releases from Microsoft are a good thing. When frameworks and features aren't tied to Visual Studio releases mean the individual teams can iterate a lot quicker (the MVC and Silverlight teams are good examples).

Haha, I was going to try and refrain from making a comment about the Enum support... but glad someone brought it up. I'm constantly haggling my friend on the EF team about this issue. I told him we're not dropping LinqToSql until this is resolved!

Apparently there are some serious changes to the core of EF that need to happen to support Enums. My friend tried to explain it to me once and it was one of those whoosh moments.

While I agree it's pretty glaring, in practice it seems pretty unsafe to use Enums along with persistent storage - as soon as the Intern comes along and adds a new enum value in the middle of the set, that column is now corrupted for all new values.

It's great that there are plenty of options in the ORM space. I still use Castle's Active Record for larger projects, and EF Code First for small ones. I spent about a year learning to use NHibernate via CAR, and it was time well spent.

I catch glimpses that indicate EF has most of the features in NH, but I wouldn't want to learn another ORM in depth -- there's just no value in it.

Reply on news.ycombinator.com