5 ms·

(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 ann

(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..."

vyrotek 16y ago
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 :)
- MichaelGG 16y ago
  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 http://ayende.com/blog/default.aspx
  - vyrotek 16y ago
    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.
  - pragmatic 16y ago
    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.
- euroclydon 16y ago
  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/ http://code.google.com/p/dapper-dot-net/
MichaelGG 16y ago
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.
- nigelsampson 16y ago
  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).
- vyrotek 16y ago
  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.
- xpaulbettsx 16y ago
  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.

vyrotek 16y ago

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 :)

MichaelGG 16y ago
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 http://ayende.com/blog/default.aspx
- vyrotek 16y ago
  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.
- pragmatic 16y ago
  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.
euroclydon 16y ago
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/ http://code.google.com/p/dapper-dot-net/

MichaelGG 16y ago

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.

nigelsampson 16y ago
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).
vyrotek 16y ago
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.
xpaulbettsx 16y ago
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.