All data access technologies are abstractions over raw ADO.NET (connection/command/datareader). So they are all slower than raw ADO.NET by definition.
Separating data access into a different object like you do with ObjectFactory provides separation of concerns, at the cost of breaking encapsulation (unless you are very careful). Breaking encapsulation like this not only causes tight coupling, but often has a negative performance impact.
Make sure to read Chapter 18 in the Expert 2008 Business Objects book, as I discuss many of these tradeoffs there.
This is all about tradeoffs.
Abstraction can simplify/reduce code making maintenance easier, but almost always at the cost of performance.
Separation of concerns provides flexibility and clarity making maintenance easier, but often at the cost of complexity (more moving parts) and sometimes performance.
The "best" data access technique is different for different orgs and apps. You might require flexibility and reduced code, so you go for a high level of abstraction and lots of separation. Sure, your code runs slower, but it is really easy to maintain and you can support multiple data sources (SQL, Oracle, etc).
Someone else might require high performance, so they go with raw ADO.NET and tighter coupling. Their code might be harder to maintain, but it will be faster.
Copyright (c) Marimer LLC