Architecture question

I have a mobile field service app written to run on WM5 CF2 and would like some advice on architecture. For this type of app, the runtime performance is crucial in relation to startup time.

I have a Data Access Layer (DAL) with various classes that provide the abstraction between business objects and the persistence layer e.g. SqlCe. One class per business object.

On top of that is the Business Logic Layer (BLL) that uses the DAL layer. This is impemented by normal classes.

And on top of that the Presentation layer implemented as a number of Forms that use the BLL layer methods only.

I have also created a 'MyApplication' class with the singleton pattern. When the class instantiates, it creates all the BLL classes, the database connection as well as all the DAL classes i.e. it creates the entire application infrastructure except forms on app startup.

Each of the DAL classes create, on instantiation, a host of SqlCeCommand objects, hooked up to the single application-wide database connection. For each unique query and SQL statement that I execute in my app, I creat a command object with the parameterised SQL text. Each command is also prepared at startup. The reason for this is that the app is completely data-driven and I have found that the only way to enhance runtime performance is to create and prepare the command objects at startup. Startup obviously takes longer, but the data-driven performance is way better this way. The downside is that the app is more memory intensive because everything is held in memory. The end result is that I have a large number of SqlCeCommand objects in memory, all hooked up to the currently (always open) database connection.

However, my forms are only created the first time it is needed, after that it is simply 'Shown' again. They also follow a singleton pattern and is kept in memory for later use.

Each of the layers sit in a different assembly.

All code examples I have seen, show that the connection/command object(s) are created when needed, used, and then disposed of again. I have tried this but it killed the app's performance.

I would like some comments on this architecture and will appreciate if anybody could point to pitfalls, etc.

Answer this question

Architecture question

Ram Pratap
One of the reasons most code samples show that connections and commands are created when needed and then disposed is that the author assumes a server-side scenario. Although this solution increases latency, it also increases throughput which is what we're looking for, server-side. In your case, though, while I think that caching the connection would be appropriate, I don't think that you'd gain nearly as much by creating all your DAL, command, and BLL objects up front.
Le Saint
hello Louis,

an option for scenario's like this could be using a kind of lazy loading strategy.
Create all dal-objects (BO-class, commands, etc) the first time they are used
reuse these instances for every subsequent usage.
This is a good strategy for instantiating (heavy) forms as well.
It's an good trade-off between memory usage and performance...imho..

kind regards,

remco van toor
WinFXGuy
This is what I currently do. The DAL objects are pretty much used all the time so they are created at startup, but the forms follow lazy load strategy. But many of them are quite heavy and I will have to free them on close...
ACCOUNTINGONLINE.US
One of the things that I can think of being useful for you could be using an object pool for Command objects. Rather than creating all commands upfront or creating them per request, an object pool could serve the purpose. You can fine tune the number of instances as per your experience with application.

Hope it helps.

Cheers!

Hammad Rajjoub
http://dotnetwizards.blogspot.com
Architecture question

Answer this question