Hello, I would like some opinions on my architecture.
My spec asks me that a Data class is my data access object and my data methods signature specs are all free of cookie values: update(int recNo, String data), delete(int recNo), lock(int recNo), etc
So I decided to use the Data class both to access the real data manager and to hide from the business layer the location of the data server. Of course, if runnning in standalone mode, no network will be used.
The awkward part is that the network layer is inside the data layer. Is that a problem? Of course every detail of my decision is explained in the choices.txt file.
I'm a firm believer in the Principle of Single Responsibilty meaning that a class should only do one thing (and do it well).
I don't believe its good design to have one class do both network code and local code.
Joined: Feb 15, 2006
So do I. So I guess I need to explain it better.
The Data class is the one the client's business methods will interface with. It's responsability is to choose between other DBMain interface implementations depending on the mode (client or standalone).
One implementation is the real class that is the entry point of the data server. Other is, let's say, a DataProxy class that takes care of the networking and communicates with the server.
Do you think it is still accumulation jobs?
Thanks for your reply
Joined: Jan 27, 2006
It sounds like your Data class is acting as a facade while choosing whether to use the local code or the network code right? I suppose as long as it implements the DBMain interface, you'll get away with it.
I would prefer to use the Factory approach, something like:
I also think that having Data implement the DBMain interface while doing something else is somewhat sneaky. If I look at the read() method in the DBMain interface, I expect it to read a record and give it back to me, not potentially lock the record before reading it and unlock it.
Joined: Feb 15, 2006
The main reason I'm doing this is to keep the Data object on client side, because it must keep internally a cookie to identify itself when talking to the server. Notice that no method of the DBMain interface contains cookie information. It is totally inspired by a web server - client communication architecture.
No, I don't intent to invoke lock and unlock methods within update/create/delete. I will just invoke isLocked so it tests the proper use of lock. If not, I'll throw an IllegalStateException (or a subclass).