SilverLight Performance

SilverLight Performance

Old forum URL: forums.lhotka.net/forums/t/7342.aspx


SouthSpawn posted on Monday, July 27, 2009

I used the "ObjectFactory" to create a seperate DataAccess class.

I enjoy the seperation of code here.

But it does seem like the database calls can be a bit faster.

2 questions here.
 
1. Will dropping the data access layer improve performance greatly?
2. I am using LinqToSQL as the data access methods.
Will going straight to ADO.net give me a boost as well?

Thanks

RockfordLhotka replied on Monday, July 27, 2009

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