5

我们目前有 2 个 MVC Web 应用程序完全独立运行。目的是将这两个站点绑定在某种具有共享授权等的 Intranet 中，并通过某种主页链接到每个站点。

到目前为止，我们已经创建了第 3 个 MVC 应用程序，并将现有的两个站点都添加为 MVC 区域，效果很好。我们还设法在一个解决方案下将每个区域分成各自的 Visual Studio 项目。

这两个领域中的每一个都由完全不同的业务部门指定，并且（通常）由不同的开发人员开发，并且需要遵循独立的发布周期。

当前的方法是将每个区域放在单独的存储库路径中，并让构建服务器为每个区域检查适当的分支，构建主 Web 应用程序（Intranet 主页），然后构建引用的区域项目。这样做的问题是我们必须每次都部署所有 3 个项目，即使只有一个区域想要发布。

这不是什么大问题（假设我们不会不小心将主 Intranet Web 应用程序的新的、未经测试的版本与该区域一起部署），但这也意味着构建服务器将使用相同的标记来标记特定构建的所有程序集版本号。

第二种方法是主要 Intranet 项目仅引用区域项目的程序集，而不是项目本身，因此它可以独立构建，而无需再次构建每个区域，反之亦然。2个问题，我看不到MS WebDeploy（由构建服务器用于发布我们的代码）仅发布某些程序集的方法。其次，单独程序集中的 MVC 区域似乎需要添加为项目引用，而不仅仅是程序集引用，因为视图不能正确动态编译（缺少 ~/Views/web.config？）

有没有更好的方法来解决这个问题？

编辑：我已经设法让主 Web 应用程序使用对区域的常规程序集引用而不是项目引用运行（不完全确定如何，它只是工作）。这意味着我现在可以根据需要独立于主应用程序构建区域。

下一个问题是使用 MSDeploy 部署所有内容。区域程序集与 /bin 目录中的主应用程序一起部署，但不包括区域的视图/脚本/内容。我正在研究将视图编译到程序集中本身的各种技术，但似乎还无法使其正常工作。

4

1 回答 1

0

令我震惊的是，这是一种非常复杂的方法。我希望不久之后，共享安全代码的好处似乎不足以证明您将经历让两个本质上不同的应用程序的代码库像这样交织在一起所带来的痛苦。

更好的方法可能是分离应用程序并为两者开发单一登录组件。如果您希望用户对两个应用程序只有一个帐户，这可以管理自己的数据库，或者如果每个应用程序都需要管理自己的用户帐户，它可以使用每个应用程序的数据库（假设它们有单独的数据库）。有许多 Membership 组件可用于为此类功能提供基础（ASP.NET MembershipProvider 和 Simple Membership，仅举两例）。

如果您希望这两个应用程序在生产环境中的同一域下运行，只需将它们部署到单独的虚拟目录中即可。您最终会得到一个类似于使用区域的 url 方案。

于 2013-06-21T10:09:13.587 回答