3 ms·

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 the

by 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/

by vyrotek 16y ago

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/