【问题标题】:Sitecore Multisite Best Practice for setting up Visual Studio Project设置 Visual Studio 项目的 Sitecore 多站点最佳实践
【发布时间】:2015-09-24 11:50:18
【问题描述】:

我正在寻求有关创建支持多站点(多租户)的 asp.net MVC Visual Studio 解决方案的最佳实践的建议。我们想做的一件事是尽量减少回归缺陷,以便开发人员不会修改错误的网站代码库等。

在我看来有两种方法。

方法一:

-Services (Project)
    |- Site A
        |-Service.cs
    |- Site B
        |-Serviceb.cs
|-Repository(Project)
    |- Site A
        |- Repository.cs
    |- Site B
        |- Repositorya.cs
|-MVC (Project)
    |-Areas
        |-Site A
            |- Controller
            |- View
        |-Site B
            |- Controller
            |- View
    |-Content
        |-Site A
            |- CSS
            |- JS
        |-Site A
            |- CSS
            |- JS

方法 2

-Services.SiteA (Project)
        |-Service.cs
-Services.SiteB (Project)
        |-Serviceb.cs
-Repository.SiteA(Project)
        |- Repository.cs
-Repository.Site B(Project)
        |- Repositorya.cs
-MVC.SiteA (Project)
        |- Controller
        |- View
        |Content
            |- CSS
            |- JS

-MVC.Site B
        |- Controller
        |- View
        |Content
            |- CSS
            |- JS

有人可以帮我看看哪个选项可能更好吗?并不是说该解决方案需要支持超过 8 个网站。

【问题讨论】:

    标签: asp.net-mvc sitecore multisite sitecore8 sitecore-mvc


    【解决方案1】:

    我还有另一种解决方法。目前正在处理一个庞大的项目,有数十名开发人员和相当官僚的部署流程,我们引入了以下方法:

    1. 项目由多个逻辑子部分组成,实际上是各个网站。
    2. 我们将每个网站设置为具有自己的控制器、视图等的 MVC 区域
    3. 最重要的 - 我们将 MVC 区域设置为可单独插入的 DLL。因此,每个网站都是解决方案下的一个单独项目,具有自己的资源和静态;在构建时,所有内容都被复制到它们所需的路径下,DLL 进入 \bin 文件夹。
    4. 还有一个用于共享(所有网站)资源的类库,它仅被需要该功能的网站引用
    5. 在 Sitecore 中,我们有同样严格的原则 - 内容、布局、渲染尽可能隔离,任何单独的内容都不得重复使用(除非来自共享资源文件夹)。

    这种方法已经为我们服务了将近一年,并且已经证明了它的敏捷性、更容易部署和相当更少的代码合并冲突。如果您只在一个站点下工作 - 您不需要重新编译和重新部署所有内容 - 只需替换 bin 文件夹中的一个 dll。

    因此,结合您的问题,方法 1 将是一个答案。

    参考资料(更多阅读):

    Sitecore MVC areas as pluggable separate DLL - making areas further more independent

    Sitecore with MVC Areas as pluggable Module

    【讨论】:

    • 谢谢@Marin,如何为每个网站提供解决方案并拥有包含所有解决方案的主解决方案。这样,每个团队/供应商都可以制定自己的解决方案。这可能需要严格的命名约定等。
    • 是的,这也适用于多种解决方案(我现在有两个,但可以是任意数量)。唯一需要注意的是确保在构建时将 Area 的 bin 编译库复制到正确的目录(主网站的 bin)。或者,您可以在一个解决方案中使用解决方案文件夹 - 任何一个都适合您
    • 嗨,马丁。对于多个解决方案选项,在解决方案中管理 web.configuration 文件的最佳方式是什么(考虑到每个站点可能需要自己的 web.config 文件来添加 nuget 包 dll 引用等)
    • 非常好的问题!!!我做什么 - 为每个网站的区域(在项目中)创建它自己的 App_Config/Include 文件夹并在那里创建 .config 文件并将所有特定于站点的设置保留在那里。在构建时,该文件将与其余的包含补丁配置文件一起复制到主 \App_config\Include 文件夹中。
    【解决方案2】:

    我个人的偏好是将每个人都聚集在同一个网站项目中,因为它迫使团队考虑他们对彼此的影响,同时也通过重复使用寻找潜在的节省。

    在您的结构中,您还应该考虑所有网站都可以使用的“共享”视图和控制器的概念。有一些简单的视图(如错误消息渲染)通常只需要应用不同的 CSS 来保持品牌形象。确保您的结构支持这种类型的重复使用。

    因此,在您提出的两个选项中,我更喜欢方法 1,并进行一些小的调整以支持共享 JS、CSS、视图和控制器。

    【讨论】:

    • 是的,你是对的,我也喜欢你提到的一样,直到我们对新的多站点有完全单独的要求
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-03-21
    相关资源
    最近更新 更多