在 asp.net 中扩展整个网站
我正在寻找最佳实践和好主意，而不是适当的解决方案。
场景：我在一家网络代理机构工作，因此我们有很多来自多个客户的网站。它们是基于我们制作的 cms 构建的，因此网站 90% 的代码都完全相同。然而，剩下的 10% 让我和我的团队感到困难，因为它不仅涉及表示层，还涉及行为逻辑（例如：网站 1 只需要用户/通行证注册，而网站 2 需要更多数据、Facebook 连接器等。但这是一个非常简单的例子）。
为我们的客户进行临时开发变得很痛苦，因为保持每个版本的一致性对我们来说真的很困难
我真正梦想拥有的是一个可以独立工作的可扩展网站，但我可以在其中覆盖部分。这种行为听起来应该像“查找特定部分，如果不存在则获取基础部分”。这些部分可以是方法、类、页面、控件、静态文件。
示例：
假设我希望 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 框架。
I'm looking for best practices and good ideas rather than a proper solution.
scenario: I work in a web agency and thus we are plenty of websites from several customers. They're built upon a cms we made, so websites are quite identical for the 90% of code. However, remaining 10% struggles me and my team as it involves not only the presentation layer but behavioral logics too (ex: a website1 requires simply user/pass registration while website2 needs more data, facebook connector, etc. But this is a very easy example).
Making ad hoc development for our customers is becoming painful as keep each version aligned is getting really hard for us
What I really dream to have is an extendible website that works by itself, but in which I can override a part. This behavior should sound like "look for the specific part, if it doesn't exists get the base one". The parts could be a method, a class, a page, a control, a static file.
example:
Suppose I want website2 to have an own login component, let's so imagine that we have a situation like:
/website_base
|_ login.aspx
/website1
/website2
|_ login.aspx
So, if I ask for www.website1.com I'll get /website_base/login.aspx, but if I ask for www.website2.com I'll get /website2/login.aspx
Any idea?
Thanks
PS: we work with asp.net 3.5 framework.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有几种方法可以实现这一目标。
方法一：
1. 将通用功能拆分为模块并创建可插拔的结构。 （就像DotNetNuke）显然，这最初会花费更多时间，但随着时间的推移，它可以使自己变得像一个产品。
方法 2：
首先 - 我会为每个客户端创建单独的解决方案，以实现更好的可维护性。这将为我在维护源代码控制时以及当一个客户端出现问题并且我们为单个客户端提供多个版本时节省很多麻烦。
其次 - 从我的核心解决方案中，我将确定每个层最常用的工件并将它们移动到核心程序集。
一个。例如，在 UI 中，您可以使用主题为每个客户端提供不同的外观。有一个带有核心站点结构的默认母版页。所有客户特定的详细信息（例如徽标、名称、联系方式等）都可以使用某些数据库字段进行配置。
b.在业务层和数据访问层 - 核心功能，如会员资格、日志记录、CMS 相关实体等，我将作为 dll
我。我将从这些核心类中导出我的客户特定逻辑。
There are couple of ways to achieve this.
Approach 1:
1. Split the common functionality in modules and create a pluggable structure. (like DotNetNuke) Obviously this will be more time consuming initially but over the period of time it can make itself like a product.
Approach 2:
Firstly - I would create separate solution for each client for better maintainability. This will save me a lot of hassle while maintaining the source control and when one client comes back with issues and we have multiple releases for a single client.
Secondly - From my core solution, I will identify most commonly used artifacts for each layers and move them to a core assembly.
a. For example – In UI you can use themes to give different looks for each client. Have a default master page which comes with the core site structure. All client specific details like Logo, name, contact details etc… can be configured using some DB fields.
b. In Business Layer and Data Access Layer – core functionalities like Membership, Logging, CMS related Entities etc I would have as a dll
i. I will derive my client specific logic from these core classes.
了解 ASP.NET MVC。它比 Web 窗体更具可扩展性，可以集成到您现有的 Web 窗体应用程序中，并且很容易构建像您所描述的那样的可重用自定义组件。
否则，我建议查看 WebParts 并为您需要的组件开发可重用的自定义服务器控件。通过这种方式，您可以将复杂的功能封装在单个 UI 控件中，而无需编写重复的代码。 WebPart 还与个性化兼容，您可以利用它来管理差异哪些站点之间使用哪些控件。
我绝对推荐 MVC 作为构建可扩展的 .NET Web 应用程序的方法，但是学习新技术总是会付出理解新范例所需的时间成本。我希望这对你有帮助。
Look into ASP.NET MVC. It is much more extensible than Web Forms, can be integrated into your existing Web Forms application, and it is very easy to build reusable custom components like what you are describing.
Otherwise, I would suggest looking into WebParts and developing reusable custom server controls for the components that you need. This way you can encapsulate the complex functionality within a single UI control without having to write repetitive code. WebParts are also compatible with Personalization, which you can leverage to manage the variance between which sites use which controls.
I definitely recommend MVC as the way to go for building extensible .NET web applications, but learning a new technology always incurs a cost in the time it takes to understand the new paradigm. I hope this helps you.
我在这里找到了一个聪明的解决方案： http://www.codeproject.com/KB/aspnet/ ASP2UserControlLibrary.aspx
看看
I found a smart solution here: http://www.codeproject.com/KB/aspnet/ASP2UserControlLibrary.aspx
Check it out