i have read some discussions about the application layers and their implementations but i don't really find something that exaclty match with my approach. More, discussions i have read make me think if my choices are not a too complicated. I want to share my view of the layered architecture i am implementing.
- The database layer : It is in this layer where we found the provided database interface. I have extended this interface by another to add some functionalities. This interface is implemented by a class that manage a memory cache and the locks. A class dedicated for reading and writing data into the file is instanciated and used by this implementation. In the core of the layer, is use a Record class that could be reused for managing different kind of data and not simply rooms. I don't have a lot of doubt about this layer. The choices are similar to what i read.
- The DAO layer : This layer defines DAO which are based on the DB layer. It converts the string arrays returned by the DB layer to domain objects (only the Room for this assignement). Those domain objects are used in the method signatures of the DAO interfaces. Actually, my room dao factory only provides methods for booking and searching records which are the functionnalities needed for the GUI layer. I prefer to implement database methods only in the database layer and don't use them in my DAO layer if it is not necessary. It is in this layer that interfaces (the DAO so) are exposed throw RMI. For the rooms, i'm going to explain how it is implemented. A RoomDaoFactory interface is defined to create RoomDao instances. There are two implementations of the RoomDaoFactory : one for local mode and one for server mode. LocalRoomDaoFactory produces RoomDaoImpl instances. RemoteRoomDaoFactory produces RemoteRoomDaoImpl instances which extend RoomDaoImpl. Both RoomDaoFactory implementations are created throw a builder which is configured using a strategy pattern. If we set the "local" strategy, builder builds a LocalRoomDaoFactory. If we set "server" strategy, it builds a RemoteRoomDaoFactory.
-> 1st question : I directly provide methods for booking and searching throw the DAO layer which consequently doesn't act as a Façade of the provided DB interface. Is it a good choice ?
-> 2nd question : Can i choose the DAO layer as the best candidate to be exposed throw RMI ?
-> 3rd question : Are the Factory, Strategy and Builder patterns correclty used here ?
- The service layer : The service read from the runtime properties if we have to use a remote DAO or a local DAO and builds the good one using the appropriate strategy. Then, it simply acts as Façade of the DAO and provides the same method (booking and searching methods here).
-> 4th question : Is the server layer correctly designed here ? Could it limit to this or should it be merged with the DAO layer to directly deal with the database layer ?
- The GUI layer : as for the DB layer i don't really have doubts. I use the MVC pattern and my controller calls the methods provided by the service layer.
Guillaume Drouet wrote:1st question : I directly provide methods for booking and searching throw the DAO layer which consequently doesn't act as a Façade of the provided DB interface. Is it a good choice ?
Well, if your DAO object is further invoking methods of DB object, then yes, DAO is acting like a facade. And it is fine. Only thing is - DAO shouldn't care about where the request comes from. The flow from DAO onwards should be exactly same in both network and standalone mode.
Guillaume Drouet wrote:2nd question : Can i choose the DAO layer as the best candidate to be exposed throw RMI ?
Better choice would be to introduce another layer - network layer. Since you've used MVC, what you can do is - in network mode, controller will communicate with network layer, which further do connection creation stuff and then invoke DAO APIs. In the network layer, you would only expose those methods which are required(search and reserve). Similarly, in standalone mode, controller will call another abstraction layer(which does nothing but to expose search and reserve methods), which won't do any connection stuff, but simply call DAO methods.
Guillaume Drouet wrote:3rd question : Are the Factory, Strategy and Builder patterns correclty used here ?
For factory pattern, I think its good choice to use factory pattern for Room object. I would suggest to use another factory for network(RMI) connection.
Frankly speaking, you'll get an idea about how flexible your application is. I didn't use lot of design patterns. Just keep the application layered and provide a descent level of abstraction. That should suffice. I didn't even use pure MVC. My view class used to call different objects' methods in different modes. And I didn't even have separate layer to deal with property file. I did it during startup itself (i.e. view used to call the property related methods).
Anayonkar Shivalkar wrote:DAO shouldn't care about where the request comes from. The flow from DAO onwards should be exactly same in both network and standalone mode.
I agree. Actually it is not the case in my design.
Anayonkar Shivalka wrote:Better choice would be to introduce another layer - network layer
So, I will integrate the management of the network mode above the DAO layer. Instead of explicitely create a network layer, why not implement it in the service layer directly ? (I think that in your view service layer disappear so the result is the same). In all cases, controller should communicate with the layer which manages the network communication and which provides the capability to use only the local mode if necessary.
You say that the network/service layer exposes only the book and search methods. Do you think that I can do the same for the DAO layer ? Is it matter to think about this ?
Anayonkar Shivalka wrote:I didn't use lot of design patterns. Just keep the application layered and provide a descent level of abstraction.
Actually, I was simply thinking about justifying some design decisions by the appropriate use of design patterns in my choices.txt. Finally, I will only mention the main design patterns (Factory, Facade, MVC) and will ignore the others when I am not sure that I provide an exact implementation of them (strategy, builder).
Guillaume Drouet wrote:Do you think that I can do the same for the DAO layer ?
You can do that. But from design perspective, better choice would be to expose those in network layer (i.e. remote interface etc.).
The reason is: consider a scenario that in future, someone decides to add another functionality - deletion of a record.
If you are exposing functionality in DAO, then
1) You'll have to make extra call in DAO (an extra method which will invoke DB layer method)
2) You'll have to expose similar method in network layer (an extra method which will invoke DAO layer method)
But, if you keep all methods in DAO and expose only required methods in network layer, then
1) All you'll have to do is expose another method(deleteRecord) in network layer - which will invoke DAO layer method. That's it.
Exposing only required methods in DAO won't bring any harm to you, but exposing it in network layer might bring some extra points to you
As I said, I'm not a design expert, and this is just my opinion - but it worked for me