You don't need an expert to answer your questions, you need someone like Captain Obvious.
I'll try…
Yes, you have to create different projects, but put them in a single solution for development and build. Only two different projects can yield different assemblies, right? Even though it's possible to imaging that the copy of the same exact assembly could play the different roles on different machine (modifying the behavior based on, say, different configuration files), this scheme would look quite artificial. The behavior of front-end and back-end is essentially different. More importantly, its very likely that those two different applications should take a form of different application type. Isn't it obvious that front-end should be a Windows application? (Well, nothing in the question sounds like a Web application.) As to the back-end, the most adequate form of it would be the Windows Service application. Now, I used to develop application which can behave as both Windows Service and a Windows application depending on how you host them, but this is a pretty tricky solution. I had very special reasons for such and advanced solution and would not advise you do go that far unless you also have very special reasons. In your case, I don't see them. So, we are ending up with separate projects and separate assemblies.
Now, can it be just two projects and two assemblies? Hardly, really. Even though it is technically possible, it would not sound reasonable. Why? If you have two applications working together, they always have a lot of code in common. At least some data type declarations, but in practice, a lot more. Hence, we are coming to having some more assemblies referenced by both application assemblies, and some have to be shared by the two.
By the way, one useful advise: if you have to prepare such lower-layer set of assemblies to be shared by some assemblies in upper layer(s), isolate UI and non-UI class libraries. There are a lot more considerations about isolation of code, aspects and
loose binding, but isolation out of UI is one of the most important things in practice. And perhaps you need to learn all those
architectural patterns like MVC, MVP, MVA and MVVM…
Should you "connect them to the same database"? Hm… Well, but how else? Connecting them to different unrelated databases? To no database? What would be the point? I hope I don't need to continue on this part.
Now, setup in a network? Well, it depends on what you need and what the requirements are. Theoretically speaking, you can indirectly interact through the
client-server system and nothing else. Is it enough? I don't know. You did not explain what exactly your application should do. I only would note that the pure client-server model is extremely poor and often is not enough. For example, you would only need to use polling,
pull technology and no
push technology, which would be extremely poor and might be wasteful. To understand the issues, please see:
http://en.wikipedia.org/wiki/Pull_technology[
^],
http://en.wikipedia.org/wiki/Push_technology[
^].
—SA
Submit an article or tip