设计：在同一台机器上调用 Web 服务的网站
更多的是设计/概念问题。
在工作中，我们决定通过 Web 服务调用我们的数据访问层。因此，我们的网站将调用网络服务来获取数据库中的任何/所有数据。网站和Web 服务将位于同一台计算机上（因此无需跨越网络），但数据库位于单独的计算机上（因此无论如何都需要跨越网络）。这都是内部的，网站、网络服务和数据库都在同一家公司内（AFAIK，网络服务不会被其他方重用）。
据我所知：网站将打开一个到 Web 服务的端口，而 Web 服务将依次打开另一个端口并通过线路连接到数据库服务器以获取/提交数据。穿越网络的旅程是不可避免的，但我担心中间的网络服务。
我确实同意功能之间需要有不同的层（例如业务层、数据访问层等），但这对我来说似乎过于复杂。我还感觉到接下来会出现一些性能问题。
在我看来，最好在解决方案中直接引用 (DAL) 组件，从而否定第一个端口到端口的连接。
任何支持和反对这个想法的想法（或链接）将不胜感激
。我们是一家 .NET 商店（从 vb 迁移到 C# 3.5）
编辑/更新 将 Dathan 标记为答案，我仍然没有完全出售（我仍然持观望态度，尽管倾斜它可能没有我担心的那么糟糕），他提供了一个经过深思熟虑的答案。我感谢所有的反馈。
More of a design/conceptual question.
At work the decision was made to have our data access layer be called through webservices. So our website would call the webservices for any/all data to and from the database. Both the website & the webservices will be on the same machine(so no trip across the wire), but the database is on a separate machine(so that would require a trip across the wire regardless). This is all in-house, the website, webservice, and database are all within the same company(AFAIK, the webservices won't be reused by another other party).
To the best of my knowledge: the website will open a port to the webservices, and the webservices will in turn open another port and go across the wire to the database server to get/submit the data. The trip across the wire can't be avoided, but I'm concerned about the webservices standing in the middle.
I do agree there needs to be distinct layers between the functionality(such as business layer, data access layer, etc...), but this seems overly complex to me. I'm also sensing there will be some performance problems down the line.
Seems to me it would be better to have the (DAL)assemblies referenced directly within the solution, thus negating the first port to port connection.
Any thoughts(or links) both for and against this idea would be appreciated
P.S. We're a .NET shop(migrating from vb to C# 3.5)
Edit/Update
Marked Dathan as answer, I'm still not completely sold(I'm still kind of on the fence, though leaning it may not be as bad as I feared), he provided a well thought out answer. I appreciated all the feedback.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是一种有问题的设计，但您的商店并不是唯一使用它的商店。
由于您使用的是 .NET 3.5 并在同一台计算机上运行，因此您应该将 WCF 与
netNamedPipesBinding结合使用，后者仅在同一台计算机上通过命名管道使用二进制数据传输。这应该会在一定程度上缓解性能问题。This is a questionable design, but your shop isn't the only one using it.
Since you're using .NET 3.5 and running on the same machine, you should use WCF with the
netNamedPipesBinding, which uses binary data transfer over named pipes, only on the same machine. That should mitigate the performance issue somewhat.我喜欢这个想法，因为它给了你灵活性。我们使用非常相似的方法，因为根据客户的安装选择，我们可以使用不止一种类型的数据库来存储我们的数据（MSSQL 或 Oracle）。
如果客户选择不使用我们的前端网站，它还使他们能够连接到我们的数据库。因此，我们几乎不需要付出额外的努力就可以获得一个开放的 API。
如果速度是您最关键的问题，那么您就必须减少层数。然而，在大多数情况下，您的 Web 服务处理来自数据库的请求所需的时间不会增加分配的时间。 （这是假设您正确地执行了 Web 服务层，如果您不注意它，很容易使其变慢。）
I like the idea because it gives you flexibility. We use a very similar approach because we can have more than 1 type of database storing our data (MSSQL or Oracle) depending on our customer install choices.
It also gives customers the ability to hook into our database if they choose not to use our front end web site. As a result we get an open API for little to no extra effort.
If speed is your most critical issue than you have to lessen your layers. However in most cases the time it takes for your web Service to process the request from the database does not add allot of time. (This is assuming you do your Web Service Layer Correctly, you can easily make it slow if you don't watch it.)
两种设计（应用程序到 Web 服务到数据库；应用程序通过 DAL 到数据库）都非常标准。与客户端交互时经常使用 Web 服务来标准化数据访问的语义。 Web 服务通常能够比底层持久性存储更准确地表示数据模型的语义，从而通过抽象和封装特定于 IO 的问题来帮助提高系统的可维护性。 Web 服务还有一个额外的目的，即通过通常可跨防火墙访问的协议为您的数据提供公共接口（尽管“公共”可能仍然意味着公司内部）。当使用 DAL 直接连接到数据库时，可以以类似的方式封装数据 IO 问题，但最终您的客户端必须能够直接访问数据库。通过将 IO 限制为明确定义的语义（通常是 CRUD+查询），您可以添加额外的安全层。不过，这对您来说并不是什么大问题，因为您正在运行一个网络应用程序 - 所有数据库访问都已通过可信代码完成。不过，Web 服务确实提高了针对 SQL 注入的鲁棒性。
除了所有 Web 服务理由之外，真正的问题是：
将使用多少？ 网站/Web 服务/数据库格式确实会给 Web 服务器带来稍高的开销 - 如果网站受到攻击，您在同一台机器上放置另一个服务之前要仔细考虑。否则，增加的小效率低下可能并不是什么大问题。另一方面，如果网站受到重创，您可能无论如何都想水平扩展，并且您应该能够同时扩展 Web 服务。
您可以获得多少收益？拥有 Web 服务的重要原因之一是为客户端代码提供数据可访问性 - 特别是当需要支持多个可能的应用程序版本时。由于您的 Web 应用程序是使用 Web 服务的唯一客户端，因此这不是一个问题 - 实际上，自行对应用程序进行版本控制可能更省力。
您想要扩展吗？您说除了单个网络应用程序之外，它可能不会被任何客户端使用，但这些东西有办法扩大规模。如果您的 Web 应用程序的范围或受欢迎程度有可能扩大，请考虑 Web 服务。通过围绕 Web 服务进行设计，您已经瞄准了模块化、多主机解决方案，因此您的应用程序可能会在扩展过程中减少烦恼。
如果你猜不到的话，我是一个网络服务迷。但以上也是我对这个问题的诚实（虽然有些偏见）的看法。如果您确实走 Web 服务路线，请务必使其简单 - 将应用程序逻辑保留在应用程序中，将服务逻辑保留在服务中，并在扩展两者时尝试在它们之间划清界限。并且一定要设计您的服务以提高效率并配置托管以使其尽可能顺利地运行。
Both designs (app to web service to db; app to db via DAL) are pretty standard. Web services are often used when interfacing with clients to standardize the semantics of data access. The web service is usually able to more accurately represent the semantics of your data model than the underlying persistence store, and thus helps the maintainability of the system by abstracting and encapsulating IO-specific concerns. Web services also serve the additional purpose of providing a public interface (though "public" may still mean internal to your company) to your data via a protocol that's commonly accessible across firewalls. When using a DAL to connect directly to the DB, it's possible to encapsulate the data IO concerns in a similar way, but ultimately your client has to have direct access to the database. By restricting IO to well-defined semantics (usually CRUD+Query), you add an additional layer of security. This isn't such a big deal for you, since you're running a web app, though - all DB access is already done from trusted code. The web service does provide an increase in robustness against SQL injection, though.
All web service justifications aside, the real questions are:
How much will it be used? The website/web service/database format does impose slightly higher overhead on the web server - if the website gets hammered, you want to consider long and hard before putting another service on the same machine. Otherwise, the added small inefficiency is probably not a big deal. On the other hand, if the site is getting hammered, you probably want to scale horizontally anyway, and you should be able to scale the web service at the same time.
How much to you gain? One of the big reasons for having a web service is to provide data accessibility to client code - particularly when multiple possible application versions need to be supported. Since your web app is the only client to use the web service, this isn't a concern - it's probably actually less effort to version the app by itself.
Are you looking to expand? You say it probably won't ever be used by any client other than the single web app, but these things have a way of gaining in size. If there's any chance your web app might grow in scope or popularity, consider the web service. By designing around a web service, you're already targeting a modular, multi-host solution, so your app will probably scale with fewer growing pains.
In case you couldn't guess, I'm a web service fan. But the above are also my honest (if somewhat biased) opinions on the subject. If you do go the web service route, be sure to make it simple - keep application logic in the app and service logic in the service, and try to draw a bright line between them when extending the two. And do design your service for efficiency and configure the hosting to keep it running as smoothly as possible.