Seperation of responsibilities for business object construction? (OO)

K

kepler

New member
For

Presentation layer
* User interface form

Business logic layer
* Factory class
* User (business object) class

Data access layer
* DataProvider interface
* SqlDataProvider (DataProvider implementation)

Does this sound right?

1) UI calls Factory.GetUser(id)
2) Factory calls DataProvider.GetDataProvider.GetObjectData(<User>,id)
3) The appropriate DataProvider implementation then makes the appropriate queries for the type.
4) The data returned from the queries is stored in an basic array (or similar) and returned to the Factory object.
5) Factory then constructs the User object and returns it to the UI
 
Still not sure about this.

I have my UIs (eg basic and snazzy), these obviously have knowledge of my business objects (eg User). I have static methods on my BOs so the UI can do things like User.RetrieveAllUsers(). The BO will then do something like DataProviderManager.DefaultDataProvider.RetrieveAllUsers(). DataProviderManager will work out which implementation of the DataProvider interface to use so 'DataProviderManager.DefaultDataProvider' is actually exposing the SqlDataProvider implementation of DataProvider. The SqlDataProvider queries the database and populates a DataSet with the appropriate data.

This is where I have a problem.

I could create a User constructor that takes a plain array, that would I think appropriately seperate the layers (and so allow me to switch from a SQL to XML datasource etc) but from a QA point of view that seems like something that could be quite risky in terms of bug generation.

It would be simple enough to have a method in the SqlDataProvider class which would know how to construct User objects and return that up the chain - but then I'm giving my data access layer the responsibility of constructing my business objects - so that's not right.

I could also create a User constructor that takes a data row - but then my BO is tied into the usage of the DataRow object, which doesn't smell right either.


I know I really need to seperate the business object representation, creation and logic actions into different classes, but I want to get this bit right first.
 
Try not to complicate too much, pick a solution that's best for you and satisfies your immediate requirements (also considering foreseeable ones).
If it works, it's sustainable and maintainable, but it breaks some rules and it's not done "by the book", who cares?
 
I was thinking that myself, but part of the point of this is to try and suggest to the devs here that seperation of concerns/responsibilities, n-tier architecture, testable code, maintainable code, etc is actually quite a good idea. :bleh: So I need to get something that's as clean as possible.
 
You must log in or register to reply here.
Back
Top