• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Network layer inside data layer

 
Eiji Seki
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

What do you think about it?
 
Kevin Conaway
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Eiji,

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.

Kevin
 
Eiji Seki
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Kevin Conaway
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sounds better

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.

Kevin
 
Eiji Seki
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic