这是有关Angular应用架构设计系列文章中的一篇，在这个系列当中，我会结合这近两年中对Angular、Ionic、甚至Vuejs等框架的使用经验，总结在应用设计和开发过程中遇到的问题、和总结的经验，来说一下Angular应用的架构设计相关的一些问题，包括像组件设计、组件之间的数据交互与通信、Ngrx Store的使用、Rxjs的使用与响应式编程思想。这些设计思想和方法，不仅适用于Angular，也适用于Vuejs、React等前端框架。当然，应用架构设计没有一个放之四海皆准的标准，他只能是根据具体情况具体分析。如果大家有更好的想法，欢迎交流。
最后在总结一下架构设计的原则。
低耦合可维护的组件
在之前的文章中，我们多次提到解耦、低耦合、减少依赖。
如果两个组件直接的依赖太多，有太多的相互调用、相互取值，那么当我的一个组件修改的时候，其他的组件也要做相应的修改。
层与层之间的依赖更加重要，如展示层和控制层，我们在展示层显示数据，在控制层处理业务、读写数据等。我们开发一个应用，也别是一个长期维护的产品时，业务逻辑肯定经常修改，相应的展示方式也会修改。如果我们能把展示层和控制层的隔离控制的很好，控制层只把需要展示的数据暴露出来，给页面需要相应的事件提供相应的接口，其他所有的控制、判断、处理都隐藏在内部。就会减少很多由于一点业务逻辑的修改而导致的Service和组件里的大量修改。
可测试的代码结构
控制层和展示层的隔离，还还来一个好处就是控制层代码的可测试性。一个Service类，就是一个简单的对象，我们可以很方便的用Angular提供的方式创建，并通过设置测试数据状态、调用业务方法、检查结果状态，来测试我们的逻辑。如果我们的Service类能够很好地测试，那么剩下的就只是把数据绑定到模板上。如果我们在展示层写了很多逻辑、判断等，那么就势必要针对组件进行测试，要对显示到页面上的数据进行判断，这就需要使用phantomJs之类的内存浏览器运行，结果的验证也比较麻烦。
除了分层的软件架构设计，我们还需要在实现控制层代码的时候，通过使用一些设计模式，合理的代码结构，让我们的代码可测试。有关设计模式和代码结构的原则，很多时候可以参考面向对象的设计原则。其中一个很重要的原则就是，一个方法就做一件事情，然后再通过适当的设计模式将这些方法组合起来。我们测试的时候，首先测试这些一个个方法的正确性，然后再测试把这些方法串起来的流程的正确性。这样就能保证整个业务的正确性。
最后，再说一下优秀程序员跟三流二手程序员的区别，优秀的程序员先设计再编码，二手程序员是先编码再改bug。
欢迎关注课程《分布式事务实践解决数据一致性》
共同学习，写下你的评论
评论加载中...
作者其他优质文章
