Best way to architect a winforms database application. 1

[jtrembla]

Ok,

I am seperating my application into the standard 3 ntier layers. It is a winforms application.

My question is how to handle database transactions.

Should I load the entire database into memory and then update the server database when the application closes?

Currently the application updates the database as each value changes in a grid or any fields. Everything is handled via stored procedures.

There are so many different examples that I am hard-pressed to find the best approach.

 

[jmeckley]

Should I load the entire database into memory and then update the server database when the application closes?

absolutely not. if this was ever needed it should be considered an edge case.

the GUI and DB are independent of each other, with no knowledge the DB even exists. With a layered architecture you would have an MVP/MVC to manage the GUI layer, then you would have a thin service layer to manage requests from the controller to the domain. within the domain you would have all your validation, business logic, factories, repositories, etc.

I like to use the Unit Of Work pattern to manage database connections/transactions. This is a common model used by NHibernate and ActiveRecord. with a web application a unit of work usually equals a request/response. With a desktop app the division is not a clear cut, so you will need to decide where logical units of work are.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[craigber]

Get the book Architecting .NET Applications. Highly recommended.

http://www.amazon.com/Microsoft®-NE...=sr_1_1?ie=UTF8&s=books&qid=1228231059&sr=8-1

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com/blog