对比两种MVC实现方式的差异

一个社交化产品，有很多业务，需要实现注册，登录，评价等功能。现在有两种实现方法，大家来讨论下这两种实现的优劣。
两种都是MVC模式，都会有controller和model，区别在于
方法A：会创建很多的service（像userService，chatService等），每个service有若干方法负责实现具体业务，比如userSerivce.login(username, passwd)，另外会有很多的bean，如userBean，chatBean，每个bean只实现get，set等方法，作为入参传给service的方法。后面就是接DAO,Mapper，数据库等

方法B：也会有类似的bean，只实现get，set方法，然后会有一些类，比如user，chat，通过调用他们的方法来实现具体的业务，后面都是一样，也是DAO,Mapper，数据库等。

可能有人觉得方案A的service和方案B的user，chat是一个意思，只是换了个名字。这里我的理解是，service本身不带user相关的任何信息，所有信息都要依靠入参的形式传入。也因此，service类本身就是一个工具类，所有的方法都可以看做是静态方法。而user，chat可以不需要入参，对于该类的不同对象，执行流程都不一样。

大家来说说这两种实现方式的差异吧。

至简主意，用B

至简主义，用B

大部分项目应该都是用的A，一些著名的框架的例子用的也是A。
B是所谓的真正的面向对象。但是有时候一些业务逻辑放在model真的很是别扭的。

推荐用A。但用B的实现方式，即把大部分业务逻辑放在model里面。

可是方式A就像是把一大坨相关业务放在一个函数里，随着业务逻辑越来越复杂，势必那个函数会越来越大，最后极有可能变成一坨if else。既不方便扩展，也不利于维护。相反用方法B随着业务的复杂，可以不断的生成user的子类，利用继承，组合，真正发挥面向对象的优势。
当然，在业务不是那么复杂的情况下，方法A的优势就是实现起来和看起来都更直观吧。

上面是我的一点想法，不知道是不是这样？

经过多年的软件工程领域的实践，终于把数据和业务逻辑分开了。你们又在想着要不要把它们放到一起。
随着业务逻辑越来越复杂，不论是A还是B都面临着相同的问题。
这个时候就看出代码层面的架构设计的功力了。
解耦合才是王道，把数据从业务逻辑里面分离出来正是为了将来业务逻辑发生变化，而数据没有变化的情况下，尽量做到互不影响。或者在数据模型发生变化时，也尽量减少对业务逻辑的影响。

实际上方案B就是把A的service和model合并在一起了。这不是好的软件工程实践。
参考一些非java的实践，好像有把DAO和model合并的。DAO里面没有业务逻辑，只有简单的增删改查，只做最简单的事，一个方法一个sql。它们合并起来倒是可以考虑。不过按照目前的主流做法，还是业务、数据访问层、数据模型层、控制层、页面层都分开的。因为随着访问量越来越大，这些不同的软件分层都可能会分别部署到不同的机器上去运行，那时候数据模型不包含任何程序逻辑，只有单纯的数据的优势就体现出来了。而且数据模型对象在action或view层包含数据库访问逻辑也不合适，不符合开闭原则和最小知识原则。

相信传统的力量：A

曾经刚开始学的时候就是用B，后来写程序多了，不知不觉就往A那里去了。

随便拉，如果系统大了，一个类里方法多了，对后人来说都是翔。想要分到子类去，不管用server还是bean都可以实现。本质上就是相同的东西，区别只是理念。

一直以来了解的MVC模式都是A实现方式，没想到还有B，学习了，不过我也觉得A要好些