Service层如何精确提炼功能去面对不断变化的需求？
0
[已解决问题]
解决于 2010-09-03 21:04
一个简单的例子：修改订单这个需求开始。
订单（Order）不具备EditOrder()的行为。一般的做法是放在服务层，例如OrderService或者OrderManager吧。根据用例驱动出不纯化的对外接口，然而，这些解接口里面的动能（方法）如何精准提炼出来？ 如例子上的EditOrder是一个单纯的功能，返回什么？参数列表是什么？这些是如何确定的？
当然返回的参数其实不难确定，但一个参数列表，十分纠结，是弱类型吗？强类型吗？当我写成EditOrder(DateTime date)、EditOrder(string num,int price)等等这里功能，我就莫名烦恼，需求总是变化，极限化问题，这个service会变得异常臃肿，很多重复的东西，不得不写一次，即使是复制粘贴也显得苍白无力，那些Extract Method的私有方法，就更显得莫名其妙了。直接用一个Domain的参数列表，有觉得不太准确，究竟是我设计问题，还是有更好的办法解决？坐等各位高见。
最佳答案
0
“这些解接口里面的动能（方法）如何精准提炼出来？”问这句话的时候，先问下实际业务是怎么样的；业务规则决定了应该有些什么方法。具体到每个方法参数列表、这个得区别对待咯。像 EditOrder ，这个方法，如果想最大限度适应变化。就两个参数 EditOrder(int orderID,OrderEntity entity); 再在 EditOrder 方法里面处理哪些属性需要更新。
正是知道业务规则，而具体的服务不能做到应对万变。各种做法总觉得怪怪的。如你的 EditOrder(int orderID,OrderEntity entity)，为什么不直接EditOrder(OrderEntity entity)，在具体的实现里拆开传入对象，再查，再更新。从这个思维可以看出，实现的具体方式影响了对外的接口，你不可能说我错，我也不可能说你错，不过，确实这些方法，有时显得莫名其妙。
直接用 EditOrder(OrderEntity entity) 有很明显的风险。主键忘记输入。忘记输入主键的话，更新无法进行。每个人的能力层次可能不同、对业务了解程度也不同、做设计的时候只能是在自己可遇见的范围、根据业务去实现功能；以后需求，或者业务规则变了， 再重构代码。
随着个人的能力的提高、业务知识的完善、就能预见更多的变化、从而做出对应的避规变化的方法、这需要个过程。
虽然，我也不觉得EditOrder(OrderEntity entity)是最好是最适合最正确，不过总比莫名其妙的参数列表显得健壮，既然提供了对外的接口，这些漏输入，少输入，输入错误都应该做出相应的处理，不是嘛？前辈！与其等待需求的变化来修改服务，有点主次颠倒感，试想一下，如果业务层变了，DAO要变？
变化的可能性太多，只有在能力、知识允许的前提下做出预防、你不可能杜绝变化。DAO 层提供的是数据、只要业务层需要的数据不变、DAO层就不应该变的。业务层的变化跟DAO层不存在必然的关系。多层架构的一个大的缺点就是会导致 级联的更改。而且一般都是 表示层-》业务层-》DAO层这样来传递。
平心自问，EditOrder(OrderEntity entity)可以适应所有变化，因为数据的范围都是围绕Domain的，所以此举能够遇见变化，不过带来的是，Service里面有复杂的验证逻辑，所以我依然迷惑，大哥，能看到问题所在吧？
严格来讲，所有从表现层传递给业务层的数据都得经过验证、而业务层所有传递给DAO层的数据也需要做验证。但是很多时候难以两全，总是需要有所取舍的；为了封装变化，多做下处理，也无可厚非；想适应变化、就得付出额外的工作。
