postgresql - "Always-Connected"Windows 客户端数据架构策略

Question

首先让我说:这是我在这里发表的第一篇文章，有点长，而且我已经很多年没有进行 Windows 窗体开发了……考虑到这一点，如果这不是直接的编程，请原谅问题，请耐心等待，因为我真的需要帮助!!

我被要求为我们公司开发一个 Windows 窗体应用程序，该应用程序与托管 PostgreSQL 数据库的中央(局域网)Linux 服务器通信。该应用程序允许用户在系统中验证自己的身份，然后与 PG 数据库进行常规交易。通常，我会建议针对 Mono 编写一个 webforms 应用程序，但客户端需要利用本地资源，例如 USB 外围设备，所以这是不可能的。虽然看起来不太清楚，但我的问题是斜体如下:

困境#1:

该应用程序旨在始终连接。 我应该如何构建我的 DAL/BLL - 它应该驻留在服务器上还是与客户端一起？

困境#2:

我一直在阅读 Client Application Services (CAS) ，它似乎非常适合身份验证，因为所有内容都通过 URI 公开。我知道 PostgreSQL 有一个 .NET 数据提供程序，但不太确定 CAS 是否可以在 Linux (Debian) 服务器上运行？相信我，我会亲自动手尝试，但我需要先想出一个合乎逻辑的设计，然后才能为“试用目的”分配资源!

困境#3:

如果 DAL/BLL 驻留在服务器上，有什么方法可以创建数据服务，并仅将这些服务公开给经过身份验证的客户端。有一个(安全)要求，即带有用户名和密码的连接字符串不能出现在任何客户端机器上......即使数据库端的安全性非常严格。我猜想这个工作的唯一方法是创建由 ASP.NET 应用程序公开的各种 CRUD 数据服务方法，并让 WindowsForms 向 ASP.NET 应用程序发出数据请求或持久数据(通过 URI)并返回一个结果集或值。 我的假设是否正确？我应该研究 WCF 数据服务吗？ WCF 能否与非 SQL Server 数据库一起使用？

感谢您抽出时间阅读本文，但要知道我正在拼命寻求有关此的任何建议!感谢一百万!!!!

编辑:

我也在考虑使用 NHibernate 作为我的 ORM

Answer 1

您问题的某些部分很复杂，超出了我的专业范围。但是，一般来说，除了 CAP 定理等之外，您几乎可以做任何您付出努力的事情。

DAL/BLL 内容通常可以驻留在任何层中。我把很多这样的东西放在我的数据库中，还有一些放在中间层，但是这是为了允许在不同的环境中重复使用，这可能是也可能不是你的目标。问题是我会仔细考虑这里的关注点分离问题以及你想放置什么样的逻辑集中。越往后，它变得越可重用，但这并不总是一个免费的权衡。

我并不完全熟悉 CAS，但从我在 MSDN 网站上看到的来看，它看起来像是 AJAX 类的东西。这可能是错误的，但如果它是正确的，那么您会遇到一个问题，因为此类请求可能是无状态的，如果您需要持续连接，这可能是一个问题。

总的来说，根据你所说的，做一个两层而不是三层应用程序听起来最干净，并且让 DAL/BLL 位于客户端，可能由服务器中的存储过程支持。然后，您可以将 PostgreSQL 设置为针对您在网络上使用的任何内容进行身份验证(如果我推荐使用 AD，则为 KRB5)。这简化了您的数据访问，并允许您根据对数据库的身份验证来控制权限。由于您可以根据 AD 对用户进行身份验证，因此您可以相应地设置权限。

一个重要的考虑因素是连接数。 PostgreSQL 确实有一些地方必须检查和迭代每个当前连接，并且在某些情况下连接启动和拆卸开销可能很大。因此，一个重要的决定将涉及连接池。您是否使用连接池来提高性能取决于您在做什么，但我已经看到 PostgreSQL 处理 600 个连接而没有出现严重问题的情况。