现在看面向对象的书，讲到设计一般都会提到MVC分离的原则，可到具体的实现，各种编程工具举出来的例子往往不是那么回事，常常令人困惑，特在此抛砖引玉，希望大家说出自己的高见。为了把事情说清楚，篇幅有点长，请大家耐心点。
举一个简单的例子，比如有一个雇员数据库管理系统，实现对雇员的雇佣、信息修改、退休或解聘的管理。
按照MVC的原则，先确定一个雇员类（Employee），它包括雇员号（emp_no）、姓名（name）、受雇时间（hire_date），部门号（dept_no）、电话（phone）、级别（job_grade）等属性，并通过employ()，modifyInfo()，retire()等方法来实现系统的功能。为了输入或显示雇员信息，定义一些界面类employFrame、modifyInfoFrame，retireFrame，在这些界面类中接受用户的请求后，分别调用Employee类的方法实现将输入的数据保存到数据库中或者显示雇员的信息。这些界面类不直接与数据库打交道，不直接执行SQL语句。具体的对数据库的操作也不在雇员类的方法中实现，而是专门定义一些数据管理的类，在雇员类的方法中调用数据管理类的方法实现数据库的存取。
在一些编程工具的例子则往往是先定义一些窗口，在窗口上放置直接访问数据库的对象，这些访问数据库的对象中包含操作数据库的SQL语句，通过这些对象实现对雇员信息的插入删除修改。象这样直接访问数据库的对象，具体的例子有Jbuilder中的JDBTable + DataSet，PowerBuilder中的数据窗口。
两相比较，无论在设计还是实现上，第二种方案当然简单快捷，但第二种方案业务逻辑划分不清楚，软件复用比较难。而第一种方案对设计水平要求比较高，实现起来也很麻烦，如果雇员类的属性比较多，为了将界面类中接收的数据传递给雇员类，雇员类的方法employ()，modifyInfo()，retire()的参数也会很多。另外数据管理类的设计也比较难。
在实际开发中，不知道大家采用那种方案，其理由是什么，请大家发表高见。
以上两种方案是我在学习面向对象设计后的一些初浅的认识，如果有不对的地方，也请大家指出来。
这个论坛人气太旺，有一点不好就是没多久帖子就被淹没了，如果大家觉得我的问题不错的话，请帮忙顶一顶，让更多的人看到，发表高见。

MVC最大的特点就是逻辑清晰，代码复用性强，后续开发和代码维护方便。

由于MVC把两层变成了三层，所以在代码效率上，应该不如你所提出的第二套方案好。

我还没有参加工作，所以对实际开发应该选择那种方案没有经验。我觉得，如果是时间很紧，工程比较小，可以用第二种方案。如果工程大，用第一种方案更好，可以避免一些不必出现的错误。

我做游戏的，在开发过程中，不知觉得总想使用MVC结构（我对他理解不深，所有开发时是不自觉的想用，因为用的也不是java而是游戏引擎）。感觉有一个好处，就是复用性好，逻辑清晰，尤其是C/S的网络游戏，很多问题本来就很难划分Server处理还是Client处理；但总觉得效率不是很高，只觉得逻辑好。不过结果是改了又改，出来时和最开始的代码几乎完全时两码事，当然最主要还是自己水平太差。

觉得如果做超大型项目还是用MVC好，如果很小很小就用封装不好的方法算了（说是这么说，自己写代码总喜欢考虑封装，不过也封装的很失败）。

这种逻辑划分还是很麻烦的，所以小事就可以不用辛苦自己大脑了，大事应该会受益非浅，估计要是划分不清几乎很难扩充和往下走的。

发到设计模式讨论比较好，这里帖子沉得快

同一楼上的说法，我在实际工作中两种方案都用过，感觉应该根据时间松紧和项目大小来定。