我们正在构建一个非常大的网站，该网站将包含一个包含许多子网站的主站点。这些通常可以在区域中实施，但这些子站点的开发周期和团队是完全不同的。我们希望能够只部署一个子站点而不会中断整个站点。我们正在尝试确定是否有一个良好，干净的方式来为每个子站点的主站点和项目创建项目。
在这种情况下，主站点具有所有核心布局和导航菜单。用户体验应该是单个站点的体验。理想情况下，子站点项目可以像MVC中的区域一样使用布局页面和主站点的其他资源。
虽然我认为通过在服务器上拼凑一些东西是可行的，但是需要一个良好的开发和调试故事。理想情况下，主站点和子站点可以加载到Visual Studio中进行开发。此外，能够在不重复每个子站点中的核心文件的情况下进行常规Web部署会很不错。
就像我提到的，我们可以使用区域，但想知道是否还有其他可行的选项。
问题答案： 这些网站可能会重用一些上下文和模型。他们是否共享内存中的实际对象，我不这么认为。每个人都有自己的实例。
将有多个按域分区的数据库。一个用于核心站点，另外一个用于每个子站点多达一个。例如，子站点A可能需要从子站点B访问一些数据。这将通过数据或服务层进行处理。
网站网址理想情况如下： 核心网站：http://host 子网站A：http://host/a 子网站B：http://host/b
要分享的具体内容：_layout文件，css，js，TypeScript，图片，凉亭包等。可能是身份验证，配置等。
authorize属性将是首选方法。表现得像单个站点的统一安全基础架构将是最佳选择。不确定这是否可行。
答案 0 :(得分：1)
这似乎是一个很好的架构问题。我不知道如何正确回答你的问题，因为我不是建筑师，也因为它似乎提出的问题多于答案...
假设典型的分层应用程序看起来像这样：
目前，我无视你想在asp.net 5 / MVC 6中使用它。
<强> Contoso.Core：
除了可能在其他图层中使用的任何其他内容之外，此图层还会保留您的entities/pocos。例如，可以是Enums，Extension methods，Interfaces，DTOs，Helpers等等。
<强> Contoso.Data：
这一层将是您存储DbContext（如果您正在使用EntityFramework）和所有DbSets<>的位置，它还将保存您的存储库的实现（而接口可能是住在Contoso.Core层...你会明白为什么以后）。
该图层依赖Contoso.Core
<强> Contoso.Service：
此层将是您的服务层，您可以在其中定义服务和所有业务规则。该层中的方法将返回实体/ Pocos或DTO。假设您使用存储库设计模式，服务将通过存储库调用数据库。
该层依赖于Contoso.Core（对于entities / pocos / dtos以及存储库的接口，因为我假设您将注入它们）。此外，您还依赖于存储库实施所在的Contoso.Data图层。
<强> Contoso.Web.Framework：
此图层将依赖Contoso.Core，Contoso.Data和Contoso.Service。
您可以在此层配置IoC Container（Autofac，Unity等），因为它可以查看所有接口及其实现。
此外，您可以将此层视为“这是我配置我的Web应用程序将使用/可能使用”的内容。
由于该图层用于网络图层，因此您可以放置与网页相关的内容，例如自定义Html扩展程序，帮助程序，属性等...
如果明天你有第二个网络应用程序Contoso.Web2，那么你需要在Contoso.Web2添加一个对Contoso.Web.Framework的引用，你就可以使用自定义Html扩展，帮助程序，属性等...
<强> Contoso.Web：
此图层是您的UI /客户端图层。
该层依赖于Contoso.Core（对于entities / pocos / dtos）。它还依赖于Contoso.Services，因为控制器会调用服务层，而服务层又会返回实体/ pocos / dtos。您还必须依赖Contoso.Web.Framework，因为这是您的自定义html扩展程序所在的位置，更重要的是，您IoC container的配置位置。
请注意，此图层对Contoso.Data图层没有依赖关系。那是因为它不需要它。你正经过服务层。
对于记录，您甚至可以用WebAPI（Contoso.Service）替换Contoso.API图层，例如，允许您创建不同类型的应用程序（winform，console，mobile等...）全部调用Contoso.API图层。
简而言之......这是您经常在MVC世界中看到的典型分层架构。
那么关于多个子网站的问题呢？它适用于所有这些？
这就是许多问题的来源......
这些子网站是否有自己的DbContext或与主网站共享同一个？
这些子站点是否拥有自己的数据库或与主站点相同的数据库？甚至不同的方案名称？
这些子网站是否有自己的URL，因为您似乎希望能够独立部署它们？
所有这些子网站的共同点是什么？
安全性，授权属性和更多东西呢？
区域的方法和将所有内容保存在一个网站中可能不太容易出错。
或者看看NopCommerce并使用插件方法怎么样？这会是另类吗？
不确定我是否以任何方式帮助过，但我很想知道别人会如何解决这个问题。
答案 1 :(得分：0)
您需要在开发机器中配置一个IIS网站。您可以使用VS Tasks自动执行其创建。您还可以在其中构建和发布您的解决方案。这将花费一些时间，但是您将具有可以通过正确配置在CD / CI构建服务器中重用的优势。
在解决方案中创建主Web项目后，将子站点创建为新的Web MVC项目，并以有意义的方式对其进行命名。例如，如果您的主Web项目名为MySite.Web.Main，则您的子站点可能是MySite.Web.MySubsite。
从所有子站点中删除global.asax和web.config，然后就可以了。发布后，所有子站点都将依赖于主站点global.asax和web.config。如果需要从子站点将配置更改添加到主web.config中，请依赖于web.config转换任务以在构建成功完成后触发。您可以为不同的环境使用不同的转换文件。
请记住，您还需要将所有自动化功能添加到CI / CD构建服务器中。
注意：在子站点项目上添加新的nuget依赖项时，有可能会创建新的Web配置。至关重要的是，所有子站点web.configs都必须以其“构建操作”属性设置为“无”的方式删除或修改，否则它将在发布过程中覆盖主要的Web配置。解决此问题的一种方法是，创建项目后立即删除子站点web.config，而是删除其内容并将“ Build Action”设置为“ none”。