讨论：关于接口化编程
        入职有一段时间了，今天来发个帖子和大家讨论下接口化编程及MVC架构。
    
        先说说自己的架构习惯，一般情况下我是比较喜欢将业务处理和web部分分开成两个包，然后搭建框架一个包，工具类一个包这种方式架构，内部一般是***.bean，***.dao，***.dao.impl，***.service，***.service.impl，***.controller，其他包这种方式，dao和service这两个为纯粹的接口，impl为实现。框架采用spring mvc+spring+hibernate+jpa搭建。对于数据库层可以是hql也可以使用sql，根据效率要求灵活选择。前端一般分包是js，css，jsp，jsp文件中不写js和css，所有用到的js全写在js文件中，这样便于查找，结构分的比较严格。

        以上是本人一直一来形成的习惯，但是目前接触的项目大部分不是按照我的这种习惯来的，是另一种习惯，整个项目似乎不写sql，完全是hql也就是完全面向对象了，也没有用接口，而是直接写出实现，比如一个简单的例子，向数据库中添加一条记录，如果是我的习惯则会这么写，dao接口中定义一个add方法，然后dao的实现中去实现它，service的接口同样定义一个add方法，然后service的实现层去写一些处理逻辑，如果要调用，则只需要调用service接口中的add方法就可以，不用关心实现，而现在的项目是少了接口这一步，希望大家各抒己见，大家在项目中是如何搭框架的，又是怎么理解接口化编程的。

        声明一下：我没说这两种方式那种好，那种不好，只是我习惯有接口那种方式，虽然它可能写的时候确实多了两个步骤，但是结构更符合接口化编程的标准，第二种方式简单，结构也还是比较清晰，希望各位能够畅所欲言，或者有什么更好的架构思路，大家不说多说说，本人借鉴下，不胜感激。。。
------解决方案--------------------

大概如此了,,,明显你们的项目结构算好的,你还没遇到过深坑,包括各种的不同风格,见怪不怪了,他们怎么用你就怎么用吧,没必要纠结,然后自己做自己的项目就用自己的风格
------解决方案--------------------
一般公司都是你说的那样，我们也是，一直是这样。
我感觉接口化的好处之一就是把业务逻辑抽象出来，在团队开发中可以提高代码的可读性和可维护性。比如接口设计好了，一个人开发一半走了，另一个人可以根据接口的设计去理解这个业务然后快速上手，可如果他看到的是一堆底层的SQL什么的，估计他要浪费更多的时间去理解，而且会比较困难。