Should client-server code be written in one "project" or two? [closed]

Question

I've been beginning a client-server application. At first I naturally created two projects in Eclipse, two source control repositories, etc. But I'm quickly seeing that there is a bit of shared code between the two that would probably benefit from sharing (in the same project or in a shared library) instead of copying.

In addition, I've been learning and trying test-driven development, and it seems to me that it would be easier to test based on real client components rather than having to set up a huge amount of code just to mock something, when the code is probably mostly in the client. In this case it seems having the client and server together, in one project, thinly separated by root packages (org.myapp.client.* and org.myapp.server., maybe org.myapp.shared. too).

My biggest concern in merging the client and server, however, is of security; how do I ensure that the server pieces of the code do not reach an user's computer? When Eclipse bundles a JAR, I'd have to pick out the server-specific bits and hope I don't miss any, right?

So especially if you are writing client-server applications yourself (and especially in Java, though this can turn into a language-agnostic question if you'd like to share your experience with this in other languages), what sort of separation do you keep between your client and server code? Are they just in different packages/namespaces or completely different binaries using shared libraries, or something else entirely? How do you test the code together and yet ship separately?

Bankhead

Answer 1

Neither. It should be 3. (common, client and server) However, it doesn't necessarily need to be three "projects". Using Maven I create three sub-modules under a master project. You can do something similar using Ant.

Hugo

Answer 2

A lot of this is going to depend on your specific implementation but I typically find that you have at least three assemblies (binaries) that are created with a project like this.

1. A Common DLL that contains shared functionality that is used by both the client and the server
2. The DLL/Exe for the client
3. The Dll/exe for the server

Using this approach you have your shared items, but you make sure that items that are server specific are never in a distribution that is sent to the client workstations.

Verada

Answer 3

I have found that at least one project per finished entity (server deployment, client binary, etc) works well with e.g. Hudson. Then you can have shared code in a basic project available to all.

Crabbed