Data Layer Architecture
Posted on 2004-10-13
I've inherited a project on which the previous architect either didn't know or care about what "good design" means.
The application being developed is a "fat" (WinForms) client with a SQL Server 2000 back-end. Unfortunately, I've been tasked with revamping the design of the application (it's best described as a 1.25 tier application). The UI makes direct accesses to the data repository, the business layer directly manipulates UI elements - it's a real mess. However, I've developed an object model that will remedy most of the existing issues. We simply have to make it a reality and then re-work the UI to consume the services provided by the objects.
I'm very concerned about the data layer. The model is hierarchical - that is class 1 can contain a collection of class 2 objects, which in turn can contain a collection of class 3 objects, and so on. If each of these classes either inherits the data access manager or declares it's own private instance, then it seems there's a lot of overhead that's unnecessary. How does one implement an "encapsulated" data layer in VB.NET which is divorced from the data objects? Is remoting with both the client and listener on the same machine the answer? If so, singleton or single use?
Several years ago, I was involved in a project that leveraged an out-of-process server for data repository services. It was a singleton (public shared) active-x app. It worked well and I believe this is the approach that we should be taking to "slim down" our current application. Am I focused on a non-issue here, or is there some other approach that I'm not giving appropriate consideration to?
Any response is greatly appreciated!