维护 2 个相似但不同的网站

Question

我有一个要求，我需要在 2 个域中托管同一个网站。两者之间的唯一区别是细微的样式差异（基本上只是徽标和标题），站点将托管在哪里以及数据库的连接字符串（数据库结构将是相同的）。

我想这与不同的 stackexhange 网站大致相似。

创建和维护它的最佳方式是什么？我想避免拥有 2 个完整的独立解决方案，因为这将成为维护的噩梦。可能需要分别对这 2 个站点进行改进。

我的项目结构大致如下：

• Web 项目（asp.net 网络表单）
• 数据项目（用于数据访问的 EF）
• 服务项目（用于从数据层返回数据并处理任何计算）

这就是我想这样做的方式：

• 在 Web 项目中有逻辑可以显示不同的样式 取决于从哪里访问。
• 为具有不同连接字符串的 2 个域提供单独的服务类。这将意味着服务层中有很多重复的代码。
• 使用依赖注入，我可以在部署时轻松更改要使用的服务类。

有点像

aspx:

<% if(domain) { %>
   some html
<% } %>

aspx.cs:

 [Inject]
 public IService service { get; set; }

IService.cs：

public interface IService
    {
        string GetClients();
    }

Service.cs：

public class DomainAService: IService
{
 DbContext db = new DbContext("connectionStringA");
    public string GetClients()
    {
        return db.Clients.ToString();
    }
}

public class DomainBService: IService
{
DbContext db = new DbContext("connectionStringB");
    public string GetClients()
    {
        return db.Clients.ToString();
    }
}

这种架构有意义吗？服务层的重复逻辑是不是有问题？ 我想知道堆栈交换站点是如何做到的。

Answer 1

您可以将配置详细信息作为应用程序设置放在 web.config 中。

所以连接字符串将在 web.config 中。如果您需要不同的徽标，您可以使用“徽标”应用程序设置。

服务层中的代码将如下所示：

public class DomainService: IService
{
    var connectionString = ConfigurationManager.AppSettings["ConnString"];
    DbContext db = new DbContext(connectionString);

    public string GetClients()
    {
        return db.Clients.ToString();
    }
}

ConfigurationManager 位于 System.Configuration 命名空间/程序集中。

所以这两个部署只在 web.config 中有所不同。

如果连接字符串包含敏感的用户名/密码，那么您可以对设置进行编码 - 请参阅此问题 Encrypting appSettings in web.config。

Answer 2

保持简单。一种网站解决方案，根据 url 呈现不同的内容和样式。

我们通过使用 master page 和 css 来做到这一点。母版页：

<%-- override css --%>
<link id="overrideCSS" rel="stylesheet" href="" runat="server" />

在后面的代码中，根据请求的域以编程方式设置 CSS 文件（例如，这可以设置徽标）并渲染任何依赖于 url 的字符串。同样，其他基础设施可以在单独的页面加载方法中隐藏/显示/修改。

当您可以这样做时，我认为不需要单独的服务：

public class DomainService: IService
{
    public string GetClients()
    {
        string connectionStringForDomain = someFunctionWhichChecksUrlAndReturnsConnectionString();
        return new DbContext(connectionStringForDomain).Clients.ToString(); // btw, why convert to string? Can't the serialiser take care of this automatically?
    }
}

如果您确实需要不同的服务类，则可以采用某种形式的依赖注入。我在跨不同的 Linq to Sql 数据上下文共享代码方面取得了巨大成功，例如，通过声明接口、在 2 个 dc 上实现这些接口以及根据需要注入相关的 dc。