jyurich (11/3/2010)
Am I the only one using Microsoft's Entity Data Model (EDM) technology as an ORM for modeling as well as for the data access layer? This is a part of their new Entity Framework model introduced in .NET 3.5 SP1.I can tell you that for years we have both written our own code generation utilities as well as implemented 3rd party variations - and the MS version is by far the most superior from many perspectives.
I highly encourage all of you SQL folks to start becoming very familiar with this, if you are not already.
On a final note, while I don't agree with auto-generating databases, I do agree with standardizing on table structures with basic things like a primary keys, status fields and naming standards.
RAP will not take foothold. Microsoft Entity Framework, however, has the full backing of Microsoft's neverending resources at its disposal 🙂
From the beginner's guide from the URL: "In fact, I've never before written a line of SQL, yet I was able to build a rich web application thanks to an ORM."
That scares the bejeezus out of me.
"Whereas one database may require a String, another may require that it be called a VarChar. When using the EF, this minor annoyance is abstracted by the database provider."
Right. Because companies are always switching out minor, unimportant stuff like their database vendor. What a useless feature. If a company is really switching from Windows+SQL Server they are probably switching to Linux + MySQL or Sun + Oracle. Neither of which would be in any way supported. Abstracting away database column types is like abstracting away the datatype of a variable. Would it be better for an application developer or worse to only have "number" instead of Int32, Int64, Float, etc. Worse. So why would it be better for a database developer? It is REALLY important to specify the right string datatype. If your ORM creates varchar and you need to support japanese characters that were only supported in Nvarchar, what do you do then?
"Kamran
22 Jul 2010 5:12 PM
It's important to note that it's still important to know SQL so you understand what is happening behind-the-scenes. If you don't, just as in LINQ-to-SQL, you could really mess up your app with unoptimized code.
It's so hard to make things like this easy for a beginner yet introduce them to important concepts like concurrency and optimized queries."
Exactly. What is EF doing when you save? When you read? What isolation level is used for reading? How can you tweak that for some cases where dirty read is allowable, and other cases where it's not? How do you begin/commit a transaction from entity framework code? How do you add error handling in the sql if the transaction failed?
"Moni
29 Sep 2010 3:23 AM
...
The whole premise of "ORMs help developers be more efficient and focused, since they don't need to spend brain cycles thinking about how to communicate with the database." is fundamentally flawed and incorrect. If you make an app you have to think about scalability and performance. In order to be aware of those issues you need to know about the SQL queries that are generated via EF and the underlying architecture. If you ignore that aspect then you'll have a serious problem sometime further in the development cycle.
...."
Again, agree completely. None of that matters in small apps, but small app shops don't tend to employ many SQLServerCentral readers.