views:

132

answers:

4

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?

+3  A: 

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.

Mitchel Sellers
+1  A: 

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.

Thorbjørn Ravn Andersen
Ah, I'm glad you mention Hudson, I've actually been spending time setting up a Hudson and Sonar server as well, but I forgot to think in terms of them.
Ricket
Use them from day one. It _Will_ save you time in the long run, and perhaps ón the short run too.
Thorbjørn Ravn Andersen
A: 

my assignment is this

How the communication is establish between different clients by the server? You can use any source for this assignment I.e, jdk etc. the assignment is in running for programme.

any one tell me about this how can do that or send me link of code

was
Sorry, this is NOT the right place. An answer is for answering, not asking another question, and furthermore as this is a homework question you need to work on it yourself or word a question in order to ask for some specific help/advice instead of requesting that someone write it for you.
Ricket
+2  A: 

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.

Chris Nava
I wasn't aware of Maven modules until now. I'm going to give it a try and it really looks promising. Thanks for the suggestion! Hopefully Hudson will play nice with the module layout too; do you have any experience with Hudson and multi-module projects?
Ricket
No. I have not yet used Hudson with a multi-module project. I suspect it will work fine but that's as far as I've gotten.
Chris Nava
Also, you can configure the Client and Server submodules to depend on and include the Common module so you only have to deliver two artifacts.
Chris Nava
Hudson picks up on modules automatically; one Hudson project for a multi-module project, and then you can see test results and build results for each module individually. It also recognizes dependencies. This solution seems to be working well so far!
Ricket