Question

我正在寻找最佳实践和好主意而不是正确的解决方案。

场景：我在网络代理商工作，因此我们有来自多个客户的大量网站。它们是基于我们制作的cms构建的，因此90％的代码网站完全相同。然而，剩下的10％让我和我的团队陷入困境，因为它不仅涉及表示层，还涉及行为逻辑（例如：网站1只需要用户/通行证注册，而网站2需要更多数据，facebook连接器等等。但这很容易例）。

为我们的客户进行 ad hoc 开发变得很痛苦，因为保持每个版本的一致性对我们来说真的很难

我真正梦想的是一个可扩展的网站，它本身可以工作，但我可以覆盖一个部分。这种行为应该听起来像“寻找特定部分，如果它不存在则获得基础部分”。部件可以是方法，类，页面，控件，静态文件。

例如：
假设我想让website2拥有一个自己的登录组件，让我们假设我们有这样的情况：

/website_base
  |_ login.aspx

/website1

/website2
  |_ login.aspx

所以，如果我要求www.website1.com，我会得到/website_base/login.aspx，但如果我要求www.website2.com，我会得到/website2/login.aspx

有什么想法吗？

由于

PS：我们使用asp.net 3.5框架。

Answer 1

有几种方法可以实现这一目标。

方法1： 1.拆分模块中的常用功能并创建可插拔结构。（比如DotNetNuke）显然这最初会耗费更多时间，但在一段时间内它可以使自己成为一种产品。

方法2：

首先 - 我会为每个客户创建单独的解决方案，以提高可维护性。这样可以在维护源代码控制的同时节省很多麻烦，当一个客户端出现问题并且我们为单个客户端提供多个版本时。
其次 - 从我的核心解决方案中，我将确定每个层最常用的工件，并将它们移动到核心组件。一个。例如 - 在UI中，您可以使用主题为每个客户端提供不同的外观。拥有核心站点结构附带的默认母版页。所有客户特定的详细信息，如徽标，名称，联系方式等...都可以使用某些数据库字段进行配置。湾在业务层和数据访问层 - 核心功能，如成员资格，日志记录，CMS相关实体等，我将作为一个DLL 一世。我将从这些核心类派生出我的客户特定逻辑。
最后但并非最不重要 - 您如何部署代码以及IIS VD结构的样子......我相信它将完全取决于解决方案的打包方式..我会为每个客户端创建一个部署包，它将给出他们能够将其部署到任何他们想要的服务器，直到您遇到有关专有软件托管的特定问题。

Answer 2

<强> Look into ASP.NET MVC 即可。它比Web窗体更具可扩展性，可以集成到您现有的Web窗体应用程序中，并且可以很容易地构建可重用的自定义组件，就像您所描述的那样。

否则，我建议您查看 WebParts ，并为您需要的组件开发可重用的自定义服务器控件。这样，您可以将复杂功能封装在单个UI控件中，而无需编写重复代码。 WebParts也与Personalization兼容，您可以利用它来管理网站使用哪些控件之间的差异。

我绝对建议将MVC作为构建可扩展.NET Web应用程序的方法，但学习新技术总是会花费时间来理解新的范例。我希望这会对你有所帮助。

Answer 3

我在这里找到了一个智能解决方案：http://www.codeproject.com/KB/aspnet/ASP2UserControlLibrary.aspx

检查出来

在asp.net中扩展整个网站

3 个答案: