来自单个服务和模型层的多个网站

Question

我想做类似于stackexchange但有自己的域名。我想在1台服务器上拥有1个单独的数据库，存储库/模型层，服务层。然后在不同的服务器或同一台服务器上，我有一个可以访问这些层的Web项目。

有没有办法在不影响这些网站的情况下实现这一目标？我正在考虑提供一个WCF服务，但是通过生成和读取xml，它似乎很慢。我可以通过其他方式实现这一目标吗？

stackexchange做了什么？

---

这是我想要完成的简单架构：

每个其他用户界面可能有也可能没有自己的数据库。

我的目标是：

我想为我们将为一组人开发的网站提供一套服务。我想将所有这些相关数据放在一个数据库中。但每个人可能需要单独的逻辑/数据库。我希望每个站点上的每个用户都有自己的身份验证。我还希望我的服务层能够区分它来自哪个域。

Answer 1

  

    

有没有办法在不影响这些网站的情况下实现这一目标？

  

在网站上？你不是指共享服务吗？

你是非常正确的，解析大量的XML会很慢，但是WCF可以以不同的方式绑定，所以你没有明确地绑定到解析XML。

更一般地说，如果你注意表现：

• 将所有内容部署到同一台服务器上 - 通过网络节省一跳。
• 不要远程连接直接。使用依赖注入动态加载提供程序，因此您仍然可以管理依赖项。另一个副产品是你的代码将在同一个进程上执行，所以你甚至不必跳过进程。
• 考虑缓存。

这只是我的头脑，我还建议通过标记搜索StackOverFlow - 特别是性能标记和其他任何您喜欢的标记：https://stackoverflow.com/questions/tagged/performance+.net

编辑：哦，我差点忘了：这听起来像是在进入多租户;你可能想看看：

• http://en.wikipedia.org/wiki/Multitenancy
• Multi-Tenant Data Architecture

我在数据架构中加入了一个，因为你提到的数据库非常多，这可能会给你一些很好的思考。

修改：

  

    

我仍然不明白我将如何上传一个新的网络项目，该项目将使用与主系统正在使用的相同的过程

  

相同的流程或相同的功能/数据？

我猜测它是你想要重用的功能和数据（通过进程我认为你的意思是相同的物理执行过程）;在这种情况下，它很容易 - 制作一个组件并多次部署/使用它。

让我们说你的共享服务是一个数据库，并且“on”是一个.Net组件，它可以进行实际的数据访问，并暴露某种接口/ API。

选项1：直接消费

• 将必要的DLL复制到新的wep应用程序中
• 添加必要的配置，引用服务托管代码。
• 让您的BL代码直接使用服务API。
• 新系统：重复。

这里有一个组件，但有多个实例 - 每个Web应用程序一个。

优点：

• 快速设置，假设服务已经有一个可以使用的API，并且处于可以按照讨论的方式部署的状态。

缺点：

• 你已经将自己硬编码为依赖;如果你对多个项目进行操作，你将会对服务的基础数据进行更改（例如） - 因为它会影响所有使用它的网络应用程序。
• 您的核心BL代码直接使用外部组件，此代码将分散在您的BL中 - 请您不需要进行重大更改。

选项2：Adapter

• 与选项1相同，但BL代码不引用服务，代码也不直接使用服务API;而是制作一个新的包（项目/组件），为你完成所有这些，然后让BL通过它。

优点：

• 不像选项1那么邪恶，你现在在核心系统代码和服务之间存在某种程度的隔离。

缺点：

• 与选项1相同，但您的代码更清晰。

选项3：Dependency Inversion (DI)

• 与选项2类似，但适配器现在是一个抽象接口，而web-apps不直接引用该服务;它们将引用包含接口的程序集 - 但这几乎就是程序集所能容纳的。
• 您可能最终还会定义一个具有系统常用类型的通用程序集 - 通常称为Plain Old C＃Objects（POCO）。
• 这个想法是接口和POCO组件不会有太大变化（参见稳定依赖原则和稳定抽象原理，两者都在上面链接的DI文章中提及）
• 接口需要由两个“边”引用，但由服务拥有 - 因此服务定义它。当您设计服务时，您显然仍然可以根据Web应用程序的特定需求进行设计。

优点：

• 完全分离==更好的依赖管理。
• 通过定义良好的界面轻松重复使用。

缺点：

• 没有真的（？）
• 可能需要更多的思考你的部分和更多的努力才能得到这个设置，但是一旦你在那里你就会有更好的基础，所以它会得到回报。