“始终连接”Windows客户端数据架构的策略

时间:2010-04-21 22:39:11

标签: postgresql architecture winforms wcf-data-services

首先让我说:这是我在这里的第一篇文章,这有点长,我几年没做过Windows Forms开发....请记住,如果这不是直接编程,请原谅我问题,请耐心等待,因为我真的需要帮助!!

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

困境#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

1 个答案:

答案 0 :(得分:0)

您的问题的某些部分很复杂,超出了我的专业知识。但是,一般来说,你可以做任何你付出的努力,CAP定理等等。

DAL / BLL通常可以驻留在任何层中。我把很多这个放在我的数据库中,有些放在中间层,但这是为了允许在不同的环境中重复使用,这可能是也可能不是你的目标。问题是我会仔细思考这里关注问题的分离以及你想要放置什么样的逻辑集中。更进一步,这变得越可重复使用,但这并不总是一个自由的权衡。

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

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

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