Language/Framework: C# / .NET + Core
I provide a desktop, multi-platform client-server API for HW control related purposes. The "Server" is communicating with multiple HW components. The "Client" is used to develop desktop applications that can communicate with the HW, using the "Server" as a proxy and for synchronization purposes.
Currently, both client and server are built to dll assemblies, and the UI for both is developed separately. This produces 4 files: 2 dll’s, and 2 exe’s (Client and Server run in different processes)
There are shared resources (as "links") in the code-base: client-server comms protocol, timeouts, etc.
The question: is it architecturally correct to "merge" the client and server API’s into a single assembly?
This will provide many benefits: single dll for development, maintenance, and deployment. The only drawback I see, is violating "decoupling". On the other hand though, these 2 components are strongly coupled, as they share comms interface and other necessary information.
is it architecturally correct to "merge" the client and server API's into a single assembly?
I wouldn't do that.
Having interfaces and necessary information in common (by which I'm assuming communication protocol and data transfer objects) does not mean that clients and server are strongly coupled, unless they share the code that does the logic or makes the functionality happen.
Having clients and server in different assemblies adds a layer of separation that forces you to keep the functionality decoupled and makes you think deeper about where certain code should reside, inside the client or inside the server. If you accidentally couple server and client too much, assemblies will no longer compile independently.
But if you deploy them together into one assembly, it will be easy to end up with too much coupled code without knowing it, simply because everything sits together and compiles together. And when you need to add another client or separate an existing one further, you will have a harder time decoupling them at that point, than if you kept things separated from the beginning.
There are good things that come out from keeping code loosely coupled, separating responsibilities and separating concerns, which you can't really substitute with "but now my build creates one dll file instead of four".
Answered by Bogdan on September 6, 2020
1 Asked on January 31, 2021 by derek
5 Asked on January 28, 2021 by timmy-zhou
1 Asked on January 26, 2021 by szeb
2 Asked on January 24, 2021 by envin
4 Asked on January 21, 2021 by ran-keren
1 Asked on January 19, 2021 by inx51
1 Asked on January 18, 2021 by scttrbrn
0 Asked on January 14, 2021 by two-horses
3 Asked on January 9, 2021
3 Asked on January 9, 2021 by finlay-weber
2 Asked on January 4, 2021 by buddygyan
1 Asked on January 3, 2021 by saif-ul-islam
1 Asked on December 31, 2020 by eyad
1 Asked on December 30, 2020 by bart-robinson
2 Asked on December 28, 2020 by keezar
1 Asked on December 22, 2020 by toivo-swn
2 Asked on December 21, 2020 by timsch
Get help from others!