通过在单用户环境中直接调用 DLL 来规避 WCF

发布于 2024-08-14 15:48:44 字数 765 浏览 3 评论 0原文

我正在帮助一家公司开发一个能够灵活支持多种部署场景的软件包。该包是用.NET 编写的,具有明确定义的BLL,并使用SQL Server 作为数据库。

该设计要求在数据访问和服务 (BLL) 与 UI 之间进行清晰的划分。此时至少有两个 UI 前端(WinForms 和 Web)。我们提出了一个 WCF 解决方案来运行 BLL 层,该层可以在强大的应用程序服务器上运行。这条路径目前已被很好地标记和理解,并且涵盖了我们所需的部署场景之一。

部署场景如下(排名不分先后):

  1. 大型多用户环境,具有 1-n 个应用程序服务器,所有服务器均位于适当大小的专用 SQL 服务器。

  2. 多用户环境在每个访问共享 SQL 服务器的个人计算机上运行 UI/BLL。

  3. 单用户环境,一台机器在其机器上运行整个应用程序(包括 SQL 服务器)。

我关心的不是场景(1),而是场景(2)和(3)。如果部署是类型 (2) 或 (3) 的风格,那么 WCF 此时不会真正为我们带来任何东西,并且会影响性​​能。有人可以建议一种设计应用程序的方法,以便在场景 (1) 中部署时,它利用在应用程序服务器上运行的 BLL,但在 (2) 或 (3) 中,整个堆栈的大部分(如果不是全部)都位于应用程序服务器上单机,WCF 可以通过更传统的 BLL 调用来绕过吗?

BLL 逻辑在所有场景之间都保持不变。就在 (2) 或 (3) 中,我希望将 BLL DLL 加载到内存中,并直接调用它,而不必通过 WCF。

我非常感谢社区对此提出的任何建议!

I am helping a company with a software package that will flexibly support multiple deployment scenarios. The package is written with .NET, has a well defined BLL, and utilizes SQL Server for the database.

The design calls for a clear delineation between data access and services (BLL) and UI. There are at least two UI front ends at this point (WinForms and Web). We are proposing a WCF solution to run the BLL layer which can be run on a beefy application server. This path is pretty well marked and understood at this point, and covers one of our required deployment scenarios.

The deployment scenarios are (in no particular order):

  1. Large multi user environment with 1-n application servers all hitting a suitably sized dedicated SQL server.

  2. Multi user environment running the UI/BLL on each individual’s machine all accessing a shared SQL server.

  3. Single user environment with a single machine running the entire application on their box (including SQL server).

My concern is not so much with scenario (1) as much as (2) and (3). If the deployment is a flavor of type (2) or (3), WCF isn’t really buying us anything at that point and would hamper performance. Can someone suggest a way an application can be designed so that when deployed in scenario (1) it utilizes a BLL running on a application server, but in (2) or (3) where most if not all of the entire stack is on a single machine, WCF can be circumvented with more traditional calls to the BLL?

The BLL logic would remain unchanged between all scenarios. Just in (2) or (3) I would like to have the BLL DLL loaded in memory with direct calls to it w/out having to go through WCF.

I really appreciate any advice from the community on this!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

无人问我粥可暖 2024-08-21 15:48:44

您可以考虑从此 CodeProject 项目进行空传输绑定。在每种情况下都为您提供相同的语义,即使用 WCF,但没有情况 (2) 和 (3) 中的开销。

You could consider null transport binding from this CodeProject project. Gives you the same semantics in every case, i.e. using WCF, but without the overhead in cases (2) and (3).

隔纱相望 2024-08-21 15:48:44

使用命名管道作为您的传输。它仍然会给您带来序列化的开销,但这实际上相当小。

Use named pipes as your transport. It will still give you an overhead for serializing, but that is properly rather small.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文