0

I am trying to figure out what the best way to structure a client-server solution. In a nutshell, my solution should have a back-end that does logic, and be able to support multiple clients in an intranet. The key here is that there won't be thousands of simultaneous requests...it will likely be capped at a a couple hundred users, so scalability isn't really an issue. (picture the service running in an office building, on a local network). I'm struggling with the overall flow of how this should work, and which technologies I should be using.

The components are as follows:

  • Logic portion, which will be on the server
  • A Database
  • Multiple desktop, mobile and web clients

So far what I've been able to come up with is the following:

  1. I need to have an application server which will be managing the API calls from the logic, and the DB access.
  2. A web server to sit on top of it, which will be managing the incoming requests.
  3. The logic portion.
  4. Clients which will conform to the API which we will define.

So I'm not sure how all this ties together...How will the "logic" interact with the application server? Does the "logic" need to be written like a server?

what I see is something like this:

        req  
client ----> web server ----> app server -----> Logic

                                |-----> DB

           response 
app server ---------> web server ----> client

So if I wanted to deploy a small-scale commercial solution, would this be the way to structure it?

Please let me know if I've been unclear, or if you need any more information.

4

1 回答 1

1

你的问题很笼统。您建议的解决方案也是通用的。如果您不提出任何特定要求，那么您将为普通用户创建一个具有平均性能的通用系统。假设您同时拥有移动、桌面和 Web 客户端，那么在前端拥有一个 Web 服务器的想法是个好主意。但接下来的问题是将所有业务逻辑保留在 AppServer 端。在批量数据操作和性能要求的情况下，您可以在数据库中包含一些逻辑，但这是一个例外而不是规则。无论如何，您应该有任何特定要求，否则设计过程看起来像风水。您还必须选择一种技术并构建堆栈。

于 2012-06-15T04:49:06.600 回答