I'm writing a client/server system. The server has a DAL/BLL design. The client is responsible for presenting the data objects and providing dialogs and wizard to allow the user to update these objects (i.e. adding/editing a user).
Initially I thought I'll just make the DAL objects have a universal data provider object so they can be used by the client as well as the server. For instance, when the data object is being used by the server, the database is the data provider; when the data object is being used by the client, the server is the data provider.
So an object gets changed at the presentation layer, for example a "user": user->setName("Fred"), and then commits it like this user->commit(), the commit method calls the data provider's commit method, which then encodes the object and sends it to the server. The server then "decorates" it with the business layer object and carries on from there.
I currently have this working as a prototype, with the DAL objects defined in a shared project that gets used by both the client and the server. The server then injects it's data provider (which uses the database), and the client injects a data provider that uses the server.
I'm wondering if this seems like a reasonable approach? I keep wondering if I need another layer rather than having the DAL objects exposed directly to the client. Maybe a data tranfer object layer, which would give me 3 layers: Data access objects, business logic objects, and data transfer objects.
Thanks.
It is not a good idea exposing 'inner objects' like objects used/returned buy the DAL. Better keep all inner objects hidden from the client and have a complete set of objects for client-server communication. It might be some extra work converting one object to another but will make upgrading the system much easier in case server and client don't upgrade together.