小编Ben*_*voy的帖子

通过洋葱架构实现基础设施移动性 - 实际意义

Onion 架构提供的主要优势之一是能够交换“基础设施”元素,例如“数据访问、I/O 和 Web 服务”( http://jeffreypalermo.com/blog/the-onion-architecture ) -第3部分/)。

Jeff 在 2008 年的帖子中表示,“业界至少每三年就会修改一次数据访问技术”。

有没有人有一个相当大的项目的例子,其中使用了洋葱架构并随后更换了关键基础设施元素?

我有兴趣了解:

  • 一般来说,这种情况有多常见?

我的直觉告诉我,虽然“数据访问技术”可能每三年修改一次,但对运行解决方案的实际基础设施进行更改(这将使实现这一好处)的频率可能要低得多?

  • 该解决方案最初运行的条件是什么?
  • 是什么导致了底层基础设施的变化?
  • 关于以这种方式改变基础设施的实际影响是否可以吸取教训,这可能使我们能够改进洋葱架构的原始实现?

我很想知道除了更换基础设施组件和实现相同的接口之外是否还需要进行意外的更改。例如,当从关系数据库模型迁移到 NoSQL DB 模型时,新基础设施是否需要将新参数传递给先前定义的方法,例如 SaveOrder(int ID) -> SaveOrder(int ID, bool AllowSiblings, bool SiblingCreated)。

  • 与传统的耦合方法相比,这种架构的实施+重新设计以迁移到新的基础设施是否显着减少了所需的总工作量?

  • 开发人员是否发现耦合的、硬引用的代码比松散耦合的、间接引用的代码更容易编写和调试,但基础设施更改的最终回报使这值得吗?

onion-architecture

1
推荐指数
1
解决办法
238
查看次数

标签 统计

onion-architecture ×1