0

我有以下项目的解决方案：

解决方案 - Website1 项目（Asp.Net MVC，azure website project with code first migration） - BLL 项目（类库） - DAL 项目（类库） - Website2 项目（Asp.Net MVC，azure webrole 项目） - Website2.Azure 项目（Website2 的云项目）

website1 和 website2 都使用 BLL 和 DAL 项目进行业务逻辑和数据访问。当我更改 DAL 模型 i DAL 类库并在 Website1 项目中运行代码第一次迁移时，开发数据库中的数据库结构发生了变化。

当我将 website1 项目发布到 Azure 网站时，生产数据库结构会自动更新，并且 Website1 在生产中工作正常，但是 website2 的生产代码停止工作，因为 website2 的生产代码使用旧的 BLL 和 DAL 来更新数据库结构体..

所以我的问题是：我如何以最好的方式管理它？

  1. 我可以以一种智能的方式同时将 2 个网站/MVC 项目部署到 Azure 吗？使用持续部署、TFSPreview 之类的......？（其中一个发布到 azure 网站，另一个发布到 azure webrole）
  2. 有没有办法告诉website2数据库结构是否发生变化都没有关系，无论如何都要继续（当然，如果在尝试使用它时缺少属性会出现错误，但其余的可以继续工作直到更新/发布网站2)..
  3. 还有什么想法...

提前致谢！

4

1 回答 1

0

嗨，我的回答将属于“任何其他想法”类别。

如果您的 BAL 依赖于 DAL，那么某些类型的更改将影响 BAL。例如，假设您有一个架构，其中有表 A、B 和 C。您 DAL 将所有这些表公开为业务实体，而 BAL 公开操作以操作它们。

现在，如果您删除表 C 并重新生成 DAL，BAL 将中断，因为它将不再能够在 DAL 中找到 C。

但是，如果您添加一个新实体 E 并重新生成 DAL，BAL 应该不会受到影响，因为它没有使用 E 进行任何操作。

您可以做的一件事是尽量减少这种强耦合，即引入数据传输对象模式。使用 DTO 模式，您将 DAL 实体/实体打包到一个完全独立的类中，并使用该类与外部域进行通信。

现在，如果 DAL 发生更改，则取决于 DAL 如何将这些更改传播到调用代码的其余部分（在本例中为 BAL）。如果 DAL 删除了 C，它仍然可以保留代表 C 的 DTO，并在上层代码要求时采取特定的操作（例如在要求 C 的列表时传递 null ..）

通常 DTO 模式用于 UI 和 BAL 之间的通信，但也可以用于从 DAL 到 BAL 的通信。

这样做的一个缺点是您将为代码添加另一层复杂性。因此，您应该在此之前考虑并消除任何其他潜在的解决方案。

此解决方案并非特定于 Azure，而是一个非常通用的解决方案，您可以将其与任何 n 层解决方案一起使用

快乐编码

于 2013-02-07T03:23:25.040 回答