【问题标题】:Should this be done with multiple or a single MVC Package?这应该使用多个还是单个 MVC 包来完成?
【发布时间】:2012-06-12 19:12:24
【问题描述】:

目前有多个(大约 15-30 个)用另一种语言编写的独立 Web 应用程序。每一个都是完全独立的,文件、图像、标题、用户、数据库等。整个9码,除了它们都存在于同一个域下并且应该具有相同的样式(但它们没有' t)。它们很快将转换为 C# ASP.NET MVC 2。它们共享相同的 LDAP 身份验证。

我想到了这些问题是应该设置为多个 MVC 解决方案还是在单个 MVC 应用程序中完成。它们都将具有相同的样式,大部分是相同的图像,并且它们共享基本功能会很好。

对我来说,这不是一个简单易行的解决方案,因为其中一些应用程序本身就相当大,将它们放在一起可能很难管理。更不用说新应用程序的开发以及添加到现有应用程序的新功能将继续进行。这可能是一个非常大的解决方案。

我对 MVC 还很陌生,尽管我现在对它有了很好的理解,但我仍在尝试重新连接我的大脑以使用方法和设计。

我想我想问的是,你们这些对 MVC 比我有更多经验的人分享一些关于 MVC 在实际使用中的启发和智慧,给我一个开始思考的方向。

【问题讨论】:

  • 独立应用程序是否都共享或可以共享相同的基础架构(身份验证、授权......)?
  • @Mark 他们共享同一个 LDAP,是的。他们只共享不同的用户表。抱歉,我不敢相信我之前没有提到过。

标签: asp.net-mvc asp.net-mvc-3 iis architecture


【解决方案1】:

我的建议是DI,像插件一样创建每个项目,这样每个项目都可以单独开发或管理而不影响其他人

我有几个使用 MEF 的项目,创建新插件或管理现有插件非常容易

这里是 MVC 和 MEF 入门...http://blog.maartenballiauw.be/post/2009/04/21/ASPNET-MVC-and-the-Managed-Extensibility-Framework-%28MEF%29.aspx

还有一个可下载的示例http://www.hanselman.com/blog/ExtendingNerdDinnerAddingMEFAndPluginsToASPNETMVC.aspx

【讨论】:

  • MEF 有很多替代容器(Spring.NET、Ninject、Caste Windsor 等)。如果您是 DI 新手,我建议您仅使用一种资源来了解设计模式:amazon.co.uk/Dependency-Injection-NET-Mark-Seemann/dp/…
  • MEF 有很多替代品,如果你要使用实体框架,MEF 应该至少是版本 1,MEF 只是一个例子
【解决方案2】:

当我将多个 Web 应用程序合并为一个时。我会考虑以下几点。

  • 如果所有应用程序共享一个共同的业务模型。
  • 如果他们共享一个公共基础设施(安全、验证、日志记录和其他......)
  • 如果他们共享相同的用户群。
  • 如果将多个项目合并为一个项目有助于我降低维护和增强成本。

在您的情况下,您说它们中的每一个都是完全独立的,那么为什么需要合并?

【讨论】:

    【解决方案3】:

    每个应用程序都有一个控制器实例是很常见的,但是如果您使用数据驱动的Front Controller 来实现它,那么在您的新 Web 应用程序框架中只需要一个类。因此,每个应用程序可能都有一个配置文件,将 URL 映射到 Command 类文件。这些可以按需构建或从资源池请求。这种方法的一大优势是这些命令中的许多将作为对现有应用程序和/或 ASP 视图的非常薄的包装器 (ServiceToWorker) 开始。

    【讨论】:

      【解决方案4】:

      只要您在应用内的页面中使用类似的标记,就可以使用所有人引用的统一样式表来实现相同的样式。通用功能可以通过统一的类库提供。对我来说,这实际上取决于应用程序之间的样式和功能到底有多接近……您是否希望每个页面上的标记完全相同,等等。

      【讨论】:

        【解决方案5】:

        我完全同意 Marks 的回答,问问自己“为什么”需要将它们结合起来。他们真的需要独立吗?

        我的其他 cmets 是....

        你应该绝对想到什么......

        1. 创建一个统一的 CSS 文件,使用您的应用程序使用的相同图像

        2. 使用 JQuery 模板/部分视图编写一些通用 JQuery(移动版,如果这些是面向公众的),以便为所有这些单独的应用程序提供统一的体验

        如果您不打算在 DAL 等方面统一您的服务器端代码,那么只需专注于客户端。

        【讨论】:

          【解决方案6】:

          请帮自己一个忙,不要将它们组合在一个解决方案中。我曾经在一个项目中工作过,我们有一个巨大的解决方案可以解决,这就是万恶之源。如果你把所有东西都放在一个解决方案中,你会增加所有项目的复杂性,你可能会想,我实际上是要通过重用一些东西来节省几行代码,但事实是您正在创建一个致命的解决方案,最终将成为瓶颈

          考虑以下几点:

          • 当您拥有超过 30-40 个项目时,Visual Studio 的性能会受到影响,这意味着您的构建将花费越来越多的时间。

          • 如果您实现构建服务器(并且应该),如果您有一个庞大的解决方案,那么仅构建与每个应用程序相关的项目的脚本将非常复杂

          现在我认为你已经完成了设计中最困难的部分:

          目前有多个(大约 15-30 个)独立用另一种语言编写的 Web 应用程序

          如果您的应用程序是独立的,则意味着它们具有独立的域,因此没有理由将它们放在单个解决方案中,甚至不将它们视为模块。

          管理独立的解决方案并不意味着它们之间不能有共享组件,(顺便说一句,当我说共享组件时,我是指基础设施组件,请不要尝试重用域对象)。

          所以现在的问题是我应该如何引用共享组件?

          最近,我发现在解决方案项目中重用基础架构组件的最佳方式是使用 Nugets。使用 Nugets 可以很容易地分发新版本的组件,所以我的建议是:在您的组织中创建一个私有 Nuget 服务器(一个简单的 IIS 应用程序)并将您自己的私有包添加到该服务器,然后从您的解决方案中引用它们

          您几乎可以在 Nuget 包中放置您需要的任何东西,包括:

          • 程序集
          • XML 配置文件(包括常见的 XML 记录器配置文件)
          • 常见的 JavaScript 文件
          • 通用样式表文件
          • 等等……

          这是一篇创建私有Nuget仓库的好文章

          创建 Nuget:

          最后在您的 CI 服务器中集成 Nuget 的创建:

          【讨论】:

          • 我不得不发表评论,但这是一个很好的答案。没想到私下里的 Nuget
          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2015-03-28
          • 1970-01-01
          • 2020-07-27
          • 2014-12-28
          相关资源
          最近更新 更多