使用共享的 BLL 和 DAL 发布多个网站

Question

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

解决方案 - Website1 项目（Asp.Net MVC，带有代码优先迁移的天蓝色网站项目） - BLL 项目（类库） - DAL 项目（类库） - Website2 项目（Asp.Net MVC、azure webrole 项目） - Website2.Azure 项目（Website2 的云项目）

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

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

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

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

提前致谢！

Answer 1

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

如果您的 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 层解决方案一起使用

快乐编码