WCF DAL 组件

Question

我有一个跨多个应用程序复制的 DAL(我知道它的设计很糟糕，但现在忽略它)，我想做的是这个......

创建一个将通过所有桌面应用程序访问的 WCF DAL 组件。任何人都可以分享他们对关注的想法吗？

我打算使用 TCP 绑定(bind)

性能方面的开销是多少(因为 1 个 DAL 组件将通过多个应用程序消耗)？？？

由于 TCP 绑定(bind)只能托管在 IIS-7.0 上，这将是硬件+s/w 方面的另一个开销(或者是否可以在顶部有 HTTP 绑定(bind)，在其下方有 TCP，以便我可以使用 IIS 版本 5 或 6 )？？？

我是否可以为多个应用程序设置多个端点，并且从性能的角度来看是好的，因为它可以帮助我们为不同的客户端应用程序创建不同的线程，并且将来也可以有不同的契约(Contract)，这样一个应用程序就不会因为 DAL 中的更改而受到影响。 .

在这种情况下首选哪种实例化模式(我们预计每天有 100 个并发用户的流量)，并且 DAL 已经使用 SINGLETON 设计模式处理了这个问题。

让我知道您对上述所有要点的想法，如果您能提供更多关于这方面的见解……将 b gr8。

提前致谢...

Answer 1

让我回答几个:

1) netTcpBinding 是一个很棒的绑定(bind) - 非常快，性能非常好 - 绝对可以!

3) 要么托管在 IIS 7.0 中，要么自行托管 - 编写一个小的 Windows NT 服务并自己处理托管。为您提供更多控制权，以及手动启动和停止 DAL 服务的能力。我什至不会费心试图让 NetTcp 在 IIS5/6 上运行某种技巧/黑客——浪费时间。

4) 同一绑定(bind)的多个端点既无用，也无助于提高性能。

5)我总是使用“每次通话”。每个服务请求都有自己的服务实例，调用被处理，然后你就完成了。这使得对 WCF 服务实现进行编程变得轻而易举——如果你使用单例，要获得任何性能，你需要担心多线程和线程安全编程——真的是一团糟。不要这样做。不，只是不要这样做。

DAL 应该始终是无状态的，并且应该以“尽可能晚地打开数据库连接，完成工作并尽快关闭连接”的模式再次运行，这非常适合每次调用实例模式。当您的服务请求进入时，连接被打开(无论如何，这些连接都集中在 ADO.NET 中的连接池中，在服务器端)，工作完成，连接再次关闭。