我有一个SQL Server数据库，它为多个ASP.NET Web应用程序提供服务。他们每个人都有自己的SiteID来区分数据。
我最近意识到让多个应用程序直接访问一个数据库并决定实现一个服务来处理所有数据库连接是不好的做法。
所有Web应用程序和数据库都位于相同的Windows 2008服务器上。
我想知道哪种服务最适合此功能。网络服务或Windows服务？在之前的工作中，他们似乎有一个在服务器上运行的Windows服务，这对Web服务有什么好处？
答案 0 :(得分：1)
虽然让多个应用程序访问一个数据库当然可以，但我认为你的意思是你试图避免在多个网站中复制所有数据访问和业务逻辑。换句话说，您宁愿拥有一个集中服务，您可以立即更新所有应用程序。
听起来您想要一个WCF服务，它可以让您作为IIS -OR-下的Web应用程序运行，作为自托管的Windows服务。如果你从来没有做过WCF，那就有一点学习曲线，但是值得学习。
IIS下的WCF，您可以获得与运行任何网站相同的好处。应用程序生命周期管理，使用IIS mms插件进行维护，在特定池标识下运行等等。
作为Windows服务，您通过服务管理器进行管理，您必须手动编写更多代码（只需一点点）来处理服务启动和关闭，当然您还没有获得应用程序使用IIS执行的生命周期管理。
您选择的可能取决于您对服务器的安全访问权限以及允许您运行的工具。如果您可以完全访问服务器，我更喜欢IIS方式，但这完全是主观的。
答案 1 :(得分：0)
Windows服务与Web服务是苹果与橙子... Windows服务本身不提供数据......
所以这里有一些选择：
传统代码中的数据访问
听起来这就是你拥有的。只要这是一个逻辑上独立的层，这可能不是太糟糕。
<强>服务
使用服务有很多优点，例如关注/实施的真正分离。您甚至可以使用与客户端应用程序不同的语言/平台实现服务。不利方面可能是表现。您可能需要对数据进行序列化/反序列化，并且无论如何都需要cpu循环。
界面驱动方法
这很好，因为您可以在应用程序中针对接口编写数据访问。该接口可以通过“传统”ADO / ORM代码实现。或者您可以使用Web服务。这具有将UI与数据分离并使自动化单元测试更容易的独特优势。