Author : ToMax
在开始正式去实现一些功能模块之前，为了让后面的东西不那么难以理解，所以简单谈一谈一个不那么有意思的情景，大多内容源于本人这一年的断断续续的java web开发和学习经验，或许会有一些帮助，如果实在觉得无聊，快速浏览一遍也未尝不可。
现在有一家非常不错的饭店，索性叫他做Spring饭店吧(不必将这家饭店与Spring框架关联，其实关系不大)。
作为一名食客，ToMax来到了Spring饭店用餐，刚进门，就被饭店的简约风格所吸引。
环顾四周，ToMax选中了一个靠近窗口的位置坐下，服务员紧随而至，不过即便服务员不过来，ToMax也准备叫一个服务员过来，因为确实是很饿了。
在从服务员的手中接过菜单后，ToMax快速地点了几道爱吃的菜，同时希望服务员能够快一点，还没开口，肚子就开始叫了起来。
服务员接过菜单，娴熟地将菜单拿到了饭店管理订单的地方。不知道该怎么描述这个地方，总之，是一个发布号令的地方，似乎每个楼层都有一个，通知相应的厨师该做哪些菜了。显然，Spring饭店是一家规格不小的饭店，有许多位大厨在工作。
与厨房外面相比，厨房里就不那么安静了，几乎所有的厨师都在紧张的工作着，认真地处理每一道菜，当然不是一道一道菜地去做，厨师们会时不时地切换操作的锅，也会腾出手来去做一些其他的工作，总之，会在同时产出好几道菜，不过似乎是分工明确，spring饭店的大师傅每个人只负责相应的菜品。
作为大师傅，当然不是需要完成菜品烹饪的所有步骤的，比如说配菜这种工作，自然会有助手在一旁完成，大师傅们更多的是对配好的菜进行加工处理。
当然，也有一些大师傅是擅长切菜、摆盘的，总之，整个厨房里，各司其职，井然有序，高效率地完成着菜品。
所以，很快，ToMax点的菜就完成了，由厨房小师傅从厨房递出，又回到了那个发号施令的地方，服务员查看了订单，将菜品快速地端到了ToMax的桌上。
其实，ToMax是非常幸运的，因为这时的食客还不算太多，用餐最高峰期，即便厨房效率再高，还是会多等一些时间，并且有时，ToMax爱吃的菜可能会因为材料耗完而做不了，不过这种情况下，敬业的服务员会及时地通知ToMax，然后更换点的菜。
看着桌上的菜，还等什么，当然是开吃了......
(这段码于0:13，真的很饿)
熟悉计算机的同学，或许会从中获得一些共鸣。那么这样的一个情景和web项目又有什么关系呢?
回想上一篇博客中，有在src目录下的cn.nuaa.tomax包下建立了许多目录,它们是controller目录、service目录、dao目录、entity目录，没有说明他们的作用，下面，将会在上述的情景中，找到他们各自比较合适的切入点。
众所周知，MVC是model、view、controller
对于用户而言，所能直接接触到的往往只有view，先入为主意味着想要应用更受欢迎，设计并实现一些风格一致、大方美观的view是非常重要的，这和一家精致的饭店是一样的，有一个清新的门面、雅致的环境，极大地提高了用餐体验。
用户与客户端之间的交互，有些是直接由客户端处理了，但还有很多需要从客户端发出请求，向服务端请求数据。而服务员是串联食客与饭店服务的中介，服务员将食客的就餐请求传递到相应业务范围的管理中心。
到了后端，对于不同业务会由不同controller处理，当然，controller本身不具备提供请求中需求数据的能力，不过没关系，作为控制器，它只需要将请求的内容交到相应的业务层去处理，并将处理的结果准确地返回给前端就可以了。上述地管理中心也是类似，将食客点的菜交给相应的厨师去完成，并将厨师完成的菜让服务员在端给客户。
service就是业务层了，比如说用户业务、订单业务等等，一个service中会集中处理一堆业务下的功能，比如在用户业务中可以包括用户的信息管理、登录、注册。在饭店中，与之类似的就是大厨们的工作了，一个大厨负责一个菜系。
service中可以做很多数据处理，但是前提是有数据，所以，会在service中使用许多的dao。Data access object，数据访问对象，几乎就是在java应用层去获取数据需要写的最底层的代码了，再向下便是框架封装的接口、JDBC、数据库了。dao通常对应的是对一张表的操作，也就是说，每建一张表，就会有一个dao，dao中会写一些对于相应表的增删查改操作。正如厨师很少去配菜，配菜由一些助手完成，而这些负责不同配菜工作的员工就和dao比较类似了。
在这里又得捎带提到entity，实体类，源于数据库，每一张表都有维护一些关系，表字段组织起来就可以抽象出一个类。一张表，就可以映射出一个实体类，表字段与实体类属性一一对应，在java中，实体类基本是这种形式的，拥有源于数据库表字段的私有化成员变量，并且为每一个成员变量都提供一组get、set方法作为访问接口。所以，对于表中的每一条记录都可以产生一个相应实体类的对象。联想一下，entity是不是就可以与配菜类比了。
顺带一提，entity与dao属于model。
回到service，有了数据，业务层就极具表现力了，可以应用各种各样的操作和算法使数据符合请求中需要的那样然后返回。大厨在有了配好的菜之后也可以尽情的展示烹饪技巧。
顺带提一下，在饭店中，厨师以及配菜的员工都是可以被替代的，当离职一名厨师，还可以找到具有相同能力的厨师，虽然他们的处理的方式未必相同，但是最终可以完成食客需要的那一道菜品。同理，对于dao和service,通常希望它们也是可以替代的，所以通常将dao和service做成interface，然后会用相应接口的实现类来表述具体的dao和service，具体会在后面展开。
到这里，是不是对于即将开展的具体功能的开发要做些什么有一个大体的认识了呢。
写了这些更多是想要再次将自己对于java web开发的印象去梳理一遍，以上纯属拙见，不过这里用来完成课设应该是足够了。
如果有帮助的话，来颗star吧