Angular应用架构设计-5:设计原则与总结

这是有关Angular应用架构设计系列文章中的一篇,在这个系列当中,我会结合这近两年中对Angular、Ionic、甚至Vuejs等框架的使用经验,总结在应用设计和开发过程中遇到的问题、和总结的经验,来说一下Angular应用的架构设计相关的一些问题,包括像组件设计、组件之间的数据交互与通信、Ngrx Store的使用、Rxjs的使用与响应式编程思想。这些设计思想和方法,不仅适用于Angular,也适用于Vuejs、React等前端框架。当然,应用架构设计没有一个放之四海皆准的标准,他只能是根据具体情况具体分析。如果大家有更好的想法,欢迎交流。

  1. Angular应用架构设计-1:显示组件和功能组件
  2. Angular应用架构设计-2:Data Service模式
  3. Angular应用架构设计-3:Ngrx Store
  4. Angular应用架构设计-4:响应式编程
  5. Angular应用架构设计-5:设计原则

最后在总结一下架构设计的原则。

低耦合可维护的组件

在之前的文章中,我们多次提到解耦、低耦合、减少依赖。

如果两个组件直接的依赖太多,有太多的相互调用、相互取值,那么当我的一个组件修改的时候,其他的组件也要做相应的修改。

层与层之间的依赖更加重要,如展示层和控制层,我们在展示层显示数据,在控制层处理业务、读写数据等。我们开发一个应用,也别是一个长期维护的产品时,业务逻辑肯定经常修改,相应的展示方式也会修改。如果我们能把展示层和控制层的隔离控制的很好,控制层只把需要展示的数据暴露出来,给页面需要相应的事件提供相应的接口,其他所有的控制、判断、处理都隐藏在内部。就会减少很多由于一点业务逻辑的修改而导致的Service和组件里的大量修改。

可测试的代码结构

控制层和展示层的隔离,还还来一个好处就是控制层代码的可测试性。一个Service类,就是一个简单的对象,我们可以很方便的用Angular提供的方式创建,并通过设置测试数据状态、调用业务方法、检查结果状态,来测试我们的逻辑。如果我们的Service类能够很好地测试,那么剩下的就只是把数据绑定到模板上。如果我们在展示层写了很多逻辑、判断等,那么就势必要针对组件进行测试,要对显示到页面上的数据进行判断,这就需要使用phantomJs之类的内存浏览器运行,结果的验证也比较麻烦。

除了分层的软件架构设计,我们还需要在实现控制层代码的时候,通过使用一些设计模式,合理的代码结构,让我们的代码可测试。有关设计模式和代码结构的原则,很多时候可以参考面向对象的设计原则。其中一个很重要的原则就是,一个方法就做一件事情,然后再通过适当的设计模式将这些方法组合起来。我们测试的时候,首先测试这些一个个方法的正确性,然后再测试把这些方法串起来的流程的正确性。这样就能保证整个业务的正确性。

最后,再说一下优秀程序员跟三流二手程序员的区别,优秀的程序员先设计再编码,二手程序员是先编码再改bug。

坚持原创技术分享,您的支持将鼓励我继续创作!