其实，我是一个程序员

    由于众所周知的原因，我失业了，这两个多月的时间真的是难熬，变成了真正的宅男，整天封锁自己，看了一本又一本书，很少出门
    春节没有回家，你们全家团圆的时候，我还在学习，大家也知道这年头找工作不容易，我也投了一个多月的简历了，才有一个电话叫去面试，最后也是不了了之，虽然我只有时间不多的java工作经验，但是对java的研究却不少，看看现在的招聘条件，基本上都是要求三年以上工作经验的，单单就是这样一个条件就把随便抓了一堆人了，所以投的简历都是石沉大海， 知道这里高手如云，所以借此宝地真心让大家帮我推荐份工作，
    本来想贴上简历，然后列出之前工作过的项目，采用的技术，“精通”SSH之类等等，但是想想不免有些俗套，所以直奔主题：假如给你一个项目做，你该怎么做？
    我想，应该根据这个问题说说我的思路吧。既然是JAVA项目开发，在独立应用程序或者C/S模式方面，java在这优势不大，我脑子八成想到的是基于B/S的WEB应用了，既然是WEB应用，免不了分为表现层，业务层，数据访问层三层架构了，加上非java的客户端编程，数据库，整个系统可以分为五层，而且，既然软件开发，不免要注重团队合作吧，一个人的知识在怎么厉害，也不能方方面面都懂的。

    说说怎么做吧。

    一：系统分析设计

    尽量有效的收集客户需求，运用面向对象的思想去解决现实中的问题，遵循面向对象设计原则，封装变化，针对接口编程，多用组合，少用继承，依赖抽象，开闭原则，高内聚，简约而不简单，开发的软件应该是以客户的需求为驱动，买单的是他们，拥抱变化，不应该凭空设想未来可能出现的需求，以免增加系统的复杂性，开发出来的软件应该考虑到可维护性（层次分明），可扩展性（策略模式），可重用性（继承），可测试性（针对接口编程），层与层之间通过接口访问，层与层之间的数据通过DTO或者领域对象传送，
    结合RUP和XP等敏捷软件发开方法学，以UML为草图（可以在草稿纸上画），得出模型间的属性及其模型间的关系，画出用例图，根据需求得出用例，以测试驱动开发开始，逐步编写代码，以迭代增量式开发完成需求，划定里程碑，经常性的与客户进行沟通以便控制项目进度和应对变化的需求，建立可执行架构以便尽早降低风险，不断的对代码进行重构和遵守代码规范，就可以以较好的可读性带来系统的可维护性
    坚持持续集成，采用构建工具和版本控制工具进行程序管理，能够减少模块间合并时产生的BUG,将BUG纳入BUG管理库，记录BUG及其解决办法，可以采取经常性开小会，了解整个团队碰到的问题，进行任务分配，团队合作

   二：表现层

   采用基于MVC模式开发，由下列部分组成：
   1，标签，（这个我有疑惑，因为如果客户端编程用到css+ ajax的话，jsp页面代码是不是用html比较好呢？）读出模型数据或者资源文件内容，接受用户输入，模型数据由领域模型或者DTO或者手工设置到HttpServletRequest属性的数据组成
   2，拦截器过滤器，进行页面级的安全检查，字符编码处理等
   3，前端控制器，所有请求都统一经过它处理，调用映射解析类分发请求
   4，应用控制器，处理具体的请求，调用业务层处理请求数据，并将处理结果作为模型放入相关作用域，返回视图接口的引用
   5，数据绑定类，将HttpServletRequest传过来的String参数转成相关类，以便传给业务层处理
   6，数据校验，验证HttpServletRequest传过来的数据是否符合期望类型，格式
   7，视图接口，持有真正视图页面的引用，通过视图解析类找到真正的视图文件
   8，视图页面：发送给客户端的代码，浏览器用它来显示给客户
   9，错误验证收集器，若出现数据若校验失败，则将错误信息放入其中，页面通过标签读出错误信息，出于可维护性考虑，错误信息应该放到资源文件中

    表现层可以通过下列四种方法访问业务对象：
   1，控制器代码中直接new一个业务对象，这种办法缺少管理
   2，单例模式，工厂方法，控制器通过单例类或者工厂方法取得业务对象，这种办法难于测试
   3，JNDI，业务对象部署在应用服务器，程序通过JNDI查找他们，这种办法依赖间通过主动查找获取
   4，IOC，业务对象的声明一般写在XML文件中，通过反射机制实例化类，提供依赖注入功能，在web应用中，管理化的业务对象一般放在servletContext中，这样控制器就可以通过它获取业务对象

    三：业务层

    要不要采用分布式应用，这个要进行些技术上的考虑，真的要为web层和business层实行物理分开吗？远程调用涉及到序列化，反序列化，DTO，网络开销，远程异常等情况，如果是因为考虑大量客户端访问而采用分布式应用的话，不妨考虑集群，通过软件或者硬件的负载均衡，实现系统的横向扩展，如果不采用分布式开发，对业务的组织方式可以采用事务脚本或者领域模型设计，事务脚本针对简单系统或者缺乏OO经验的团队设计，一个事务脚本是一个访问数据库且计算的方法，他通过操作DTO而不是领域对象。相对于事务脚本，领域模型驱动设计是解决复杂业务逻辑的好办法，由众多大大小小的领域类组成，这些领域类对象现实生活中的实体，肉感十足，而不是大量的气喘息息的DTO组成，领域模型建模中，类大致可以分为：
     1，实体对象，具有唯一业务标识，有状态和行为，被持久化到数据库
     2，值对象，不代表唯一对象，可以交换使用
     3，工厂，定义创建实体的方法
     4，仓库，定义操作持久对象的接口方法，功能与DAO类似，不同的是仓库处于业务层而DAO处于持久层
     5，服务，调用仓库和持久对象进行业务逻辑处理
     业务层封装通过POJO facade或者session facade将业务处理结果传给表现层或者远程客户。如果涉及到远程访问，可以采取RMI，EJB，web service ，dwr（客户为浏览器）等等，也可以不用封装业务层，采用暴露领域模型直接将服务对象处理结果返回领域模型给表现层，采用pojo facade 或者暴露领域模型的方法不能提供分布式事务管理，也不方便远程访问，要用到分布式事务管理和远程访问，可以采用session facade 封装业务逻辑，实际业务处理委托给封装了无状态会话Bean后面的pojo类执行
    SUN公司早先投入大量精力，终于成功的推出了让他们丢大脸的EJB2技术，借助业务委托和服务定位器，可以隐藏远程客户端程序的JNDI查找代码。

    四：持久层

    基本上，程序很少直接使用JDBC进行数据库操作，如果用JDBC，应该在JDBC上面采用抽象的封装，使得程序不必关注连接的初始化和关闭，但是最好采用ORM,SqlMap框架作为持久层框架负责业务层数据与数据库打交道，原则上，如果数据库的控制权在开发者手中或者数据库表跟持久对象之间存在很好的映射关系是采用ORM框架，其他情况宜采用SqlMap框架
    如果采用ORM,则要考虑的方面有
    1， 表间关系，一对一，一对多，多对一，多对多四种关系，实体如何与表间映射
    2， 资源连接工厂，资源连接工厂一般在应用中只有一个，最好由业务层的IOC容器管理
    3， 对象模型与数据库模式之间的声明式映射，类映射到表，属性到字段，关系映射到外键
    4， 连接接口，提供增删查改接口，获得事务接口
    5， 事务接口，由框架统一管理事务
    6， 查询语言，包括一般查询和条件查询
    7， 缓存，延迟和主动加载，提高系统性能。
    8， 脱钩挂钩，通过脱钩将持久对象能在表现层使用，挂钩能够使托管对象重新变成持久对象
    9， 分页机制，避免将大量数据装入内存

    针对遗留数据库应采用SqlMap框架,一个好的SqlMap框架能够提供：
    1， 充分利用目标数据库的特殊优化，更加精确的控制SQL语句
    2， 分离SQL语句，将SQL语句从程序中剥离出来，放到XML文件去，提高系统的可维护性  
    3， SqlMap API,使用内联参数或者外部参数，将参数类映射成JDBC PreparedStatement 参数，或者将ResultSet映射成JAVA类
    4， 延迟加载，只有对象的属性第一次被访问时才加载改属性对象
    5， 缓存，根据对象的读写频度采用不同的缓存算法
    6， 动态查询，对分页或者条件查询有很好的支持
    7， 事务管理，提供事务操作接口，以便在程序中划分事务
    8， DAO框架，封装SqlMap API，对业务层隐藏具体的数据操作

    五：核心通用模块

    1， 事务处理
        为了可维护性，宜采用声明式事务，免除持久层中的事务代码，确定事务的传播行为，隔离级别，只读提示，回滚规则等，程序应该在业务层划分事务，然后委托持久的事务管理器进行事务管理，以AOP或者CMT为基础提供对业务对象的方法拦截， web请求到达业务层，业务层通过IOC管理的资源连接工厂获得连接，绑定连接至线程（数据访问层要用到此连接），调用事务拦截，打开事务，调用服务对象，服务处理完毕后，根据有无异常决定提交还是回滚，关闭连接。向web返回业务处理结果
     在共享数据的情况下，还要考虑并发，处理并发可以采用serializable的事务隔离级别，Read committed加上乐观锁或者悲观锁等三种方法，采用serializable的事务隔离级别对系统性能产生很大的开销，并且不能享受并发带来的好处，同时也增加了死锁的发生几率，一般采用Read committed加上乐观锁的并发处理策略。

     2，验证数据
       验证可在三个层次验证：
       客户端验证：采用javascript技术，这个由浏览器执行
       表现层验证：对HttpServletRequest传过来的数据进行验证，可参考上面的表现层介绍
       业务层验证：主要是进行业务逻辑的验证，可能用到数据库的数据

    3 单元测试
       采用单元测试工具，单元测试能够较少BUG的产生，从而降低维护时间，测试应该尽量避免对环境或者特定框架的依赖，采用单例模式和静态工厂方法不利于单元测试，针对接口编程和策略模式可以容易使用模拟对象进行测试，测试可分别对表现层，业务层，数据访问层进行，如果非要只选一个，建议在业务层进行，通过建立一个测试基类，在初始化方法中实例化一个IOC容器管理对象的上下文对象，在销毁方法中将上下文对象置空，然后让每个测试类继承这个测试基类

    4 异常处理
      异常可以分为系统异常和应用异常，系统异常是客户期望的异常，在程序中要捕获，系统异常是客户不可预料的异常，一般不用捕获，按照分层设计，每一层应只抛出该层对应的异常，表现层抛出表现层异常，业务层抛出业务层异常，数据访问层抛出数据层访问异常，具体的数据访问代码抛出的SQLException应该转换成RuntimeException,在异常的最初产生位置要记录日志，以便排错

    5 安全方面
      可以分为页面级和方法级安全检查，页面级可以通过定义Filter进行URL的拦截，检查用户是否登录，是否具有访问某个URL的权限，方法级安全检查可以用AOP进行拦截，判断用户的操作权限， 如果进行细粒度的安全检查，可以在程序中硬编码写入。

    6 日志
      根据程序需要，调整日志级别，将日志分为跟踪日志，异常日志，审计日志，决定在开发环境和生产环境下的不同的日志行为

     六： 数据库
    
     1，应该以领域分析为主，得出持久对象类，再根据持久对象类确定数据库表，而不是由数据库表驱动持久类。
      2，oracle调优网上一大堆，我也没什么好说的。
     


     七： 工作流（待续）

     八： 客户端编程（待续）

     九： 性能调优（待续）

     十： 工具（待续）

感觉像是写了篇大学毕业论文……

写这么，没认真看完
看楼主应该看了很多j2ee方面的书

呵呵，像论文是我看书看的太多了，开发类的书就买了两千多块钱了

上面的分析设计参考自

《深入浅出面向对象分析设计》
《深入浅出设计模式》
《领域驱动设计》
《pojos in action》
《敏捷软件开发》
《J2EE 核心模式》
《探索极限编程》
《统一过程--实践者指南》
《测试驱动开发》
《重构》
《Expert One-on-One J2EE Development without EJB》

等书目

哎，此帖人气不咋嘀，还是回去啃书吧

很经典哦~分析的很好~值得学习~

非常不错!要是能用这些理论结合一个好的项目来进行串讲,对人的提升还是比较大的!
期待楼主继续!关注中...

。。。。。一本书没看。。继续敲代码。。。。。

写得好，搂住继续

说说是没用的