I’m currently on the analysis phase of a project I need to complete for a course, so it doesn’t just have to work, it needs to have good class design, OOP good practices and all that.
It’s a desktop program (C# and WPF) with access to a local, single-file, single user database (SQL Server CE).
My domain has a master table containing “documents”. I want the user to open a single document from the database, and that will retrieve from the database and store in memory the complete graph: each single document object has various collections of “son” and “grandson” objects. From memory to user interface, where the user will be free to manipulate the document but it’ll only be persisted when the user clicks on “Save”, just as a Word document, for example.
Other question: giving the nature of the application, it’s be best to open a connection to the database and keep it open for as long as the application is running, or it would be best to open a connection only when the app is actually saving or reading data?
I’m not looking to see my problem implemented, just some suggestions for good design patterns relevant to my domain (links would be good, too). Also, the domain is quite simple so I could implement those patterns myself without using a OR/M framework such as NHIbernate or Castle (in fact I believe NHibernate is too much of a hassle for a simple problem like this), but I wouldn’t be against some simple, small and easy persistence framework.
I would abstract the database into a Connection Factory pattern object. That way you can create connection objects as needed, and they can destroy themselves when they go out of scope.
Doing it that way means that you can use a persistent connection, or constantly make a bunch of new connections. It doesn’t matter because the implementation is abstracted away.
That being said, I’d probably implement it as a persistent connection – there’s overhead associated with making a new connection for every single query.