Erland Sommarskog said:
I learnt to program in Simula, long before O-O became the buzzword of the
say. Chance had it later that I would mainly work with relational
databases.
Where for various reasons the object-oriented paradigm has not had equal
success.
I started programming prosessionally in 1971 well before any of this was in
place.
I've heard this jazz about removing object-relational impedance, but I'm
afraid I'm skeptic to that LINQ is successful to that end. Your code may
look prettier, and unless you are the one who builds the entity model
and needs to see those pesky database tables, the programmers may not
even have to bother about the relational model.
What is it that I have explained to you what LINQ is about that you don't
understand and OOP, and I am NOT talking Linq-2-SQL?
And there are times when I have used SQL Command Object with T-SQL inline or
in a sproc to query the database with ADO .NET Entity Framework in the same
solution. It depends upon the needs. But no matter what type of mechanism I
use to query the database with results returned, the result is encapuslated
in an object or objects.
The entity on the model is an object. Therefore, I can use the entity
instaciated new and fill the entity as an object, even if the query was
using T-SQL and a datareader on a table that was also on the model, not
likely to happen that way but it can, or I use a DTO a Data Transfer Object
and return the DTO.
If the objetcs are in a collection, then I can use Linq-2-Object againt the
collection of objects in memory and query it, never having to go back to the
database.
And, well, as long as your performance is good, there is no reason to
lament. But there are few tools that are so powerful to make things to
really slow like a relational database engine, so chances are good
that you sooner or later hit a performance problem. And to address this
you need a good understanding of the DB engine and how it is best used.
Or you need to talk to a DBA who can understand your LINQ and entity
model. And now the impedance is back in town, just in a different
place.
What one needs to know is what type of query to use and the resulting T-SQL
that's going to be produced, which there are tools that allow the programmer
to look at the results. This would allow a DBA to say not to use the query
and formulate it another way for faster results. It could be that lazy
loading is needed instead of a fast loading query. There are options and
paths a programmer can take in querying the database with returned results
and speed.
Note here that I'm not saying that "relational" is better than "object-
oriented". There are simply two realms, and that is something we have
to live with. The performance issues typically manifest themselves in
the relational realm, so it's risky trying to shy away from it.
I don't think there is a speed issue in the ORM solution if the ORM lets the
programmer take complete control by removing the associations off of the
Entity Model that were derived from the database and its tables. ADO .NET
Entity Framework allows the programmer to do just that, which is what I use.
And if one needs speed against the model, one is going to use ESQL not
unlike T-SQL and not use Linq-2-Objects against the model. Those two ways of
doing things against the model gives the speed for the query with complete
control of the model.
I'll toss my C#.net MCP out there.
But below is more of my expertise now with SOA and where I am geared
towoards, which concerns speed, design patters, unit testing and OPP.
http://www.dofactory.com/Framework/Framework.aspx
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4539 (20091024) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com