Hi,
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.
Thanks