分享一下自己的经历,best practices 其实在不同时期有不同的理解,有时候甚至变化很大,我自己也有迷惑的时候。 我是做ror出身的,rails 就是标准的MVC,再加上一个helper目录;
初入行时候接触的项目,controller都很臃肿,后来,提倡的是 thin controller, fat model, 于是大家又把逻辑搬到model里面;于是model又变得非常臃肿,里面包括了很多业务逻辑,耦合太高,写起测试来非常痛苦;
另外,原本helper只应该放关于view的method, 却很快变成了垃圾桶,很多不是view相关的方法都扔在了helper目录下,甚至很多controller要include 其他controller 对应的helper, 只是因为那里定义了一个可以用到的方法。
再后来,有了presenter的概念,helper目录基本就不用了;每个controller都有对应都presenter,再有,就是建立了service的目录,把业务逻辑从model里面抽离处理; 这样的结构稍微清洁了一点,测试也好写了很多。
但是在我看来,我们项目presenter/services这种分层没有什么标准,有些同事还是把这种分层当作万能垃圾桶,什么都建一个,甚至业务/运算都扔在presenter里面;services 的分层也是一个问题,很多只是根据model的来分,而不是业务; 最近有看了一下elixir对应的phoenix , 它引入了context的概念,更偏重于业务划分, 我感觉这是一个比rails 更合理的分层。
PS:非常喜欢老师的这个课程,收益良多,能否建立微信群/slack/小密圈 之类的以便课程结束后能继续与老师和各位同行交流。 谢谢
展开
作者回复: 多谢你的分享!后续的安排看编辑怎么协调吧。