我有以下项目的解决方案：
解 - Website1项目（Asp.Net MVC，代码首次迁移的azure网站项目） - BLL项目（班级图书馆） - DAL项目（班级图书馆） - Website2项目（Asp.Net MVC，azure webrole项目） - Website2.Azure项目（Website2的云项目）
website1和website2都使用BLL和DAL项目进行业务逻辑和数据访问。当我在DAL类库中更改DAL模型并在Website1项目中运行代码时，首先在开发数据库中更改数据库结构。
当我将website1项目发布到Azure网站时，生产数据库结构会自动更新，而且Website1在生产中工作正常，但随后网站2的生产代码停止工作，因为website2的生产代码使用旧的BLL和DAL更新的数据库结构..
所以我的问题是： 如何以最佳方式管理？
提前致谢！
答案 0 :(得分：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层解决方案一起使用
快乐编码