1

Premise:

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. system topology

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.

Thanks

Improve this question
7
  • This will provide many benefits: single dll for development, maintenance, and deployment In what respect are those benefits? It is pretty common for a solution to have dozens of assemblies, one more hardly matters.
    – John Wu
    Jul 15, 2020 at 22:46
  • in this case, we're trying to keep a minimal footprint. But you're right, this "benefit" purely semantic, and that's one of the reasons I posted the question.
    – BoJl4apa
    Jul 15, 2020 at 23:33
  • If you're trying to save memory usage on a mobile device, separate assemblies may actually be preferable. If you have one big assembly, everyone who installs the app is also installing server-side-only code that they don't need.
    – John Wu
    Jul 16, 2020 at 7:00
  • @JohnWu: Beware of different people meaning different things by "assembly". Some mean it to be equivalent to a DLL, others equate it to the combined output of a build (i.e. the application and its libraries together), others refer to every project as an assembly. I'm not saying you're wrong but your comment is open to different interpretations.
    – Flater
    Jul 16, 2020 at 11:33
  • (1) How is the client communicating with the server? Is it a local web request? Windows service? CLI command? (2) Why do you need multiple clients? (I'm not implying you don't, I'm asking for the reason why) (3) Similarly, is there a reason why the client/server must run in different processes or is that simply how it currently is, without it being a requirement? (4) When you say "merge", do you mean making a single DLL out of them, or rather merging the server and client applications themselves? (which can be comprised of multiple DLLs)
    – Flater
    Jul 16, 2020 at 11:38

1 Answer 1

Reset to default
2

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".

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.