随着web2.0技术的兴起,在J2EE框架设计上存在很大的争议,希望大家从不同的角度提出问题和一些建议

应该是web层的开发量最大，而且现在的web框架都有自己比较独特的处理方法，这需要美工理解，这是一个需要配合的工作。
业务层应该可以和DAO分开，这需要在设计的时候仔细的考虑。
对于整体系统的构架，应该保持单个应用的最简单，应用之间也保持最小的耦合，同时单个应用应该是可以横向扩展的。

解决方案 »

  1.   

    学习中！另外我问一下web2.0是什么的一个标准还是什么？菜鸟问题，勿见笑！
      

  2.   

    laoer(laoer.com)能否谈谈你在项目开发的过程中遇见的一些问题?(非技术细节问题) ,最好能从项目开发过程中哪些地方会影响到开发效率和可维护性等的角度谈谈
      

  3.   

    hubing2008(曾经沧海难为水，除却巫山不是云(☆☆☆)) 对web2.0的定义存在很大争议,在这里不发表个人意见,或者从目前互联网技术上自己体会吧
      

  4.   

    web2.0一般要求产品开发相对迅速，也就是产品周期短，按照我的方法和原则，一般是由时间来定产品，比如，产品周期为3个月，那么在这3个月内定能做多少东西出来，我一直认为产品在精而不在多，可以在3个月内把重要的部分做好，做精，展现出创新即可，在之后的时间里渐进扩展。
    互联网产品开发是一个需要多方协作的工作，技术、产品策划、UI的人员要共同参与，我一般建议这3方人员一起来确定需求，UI迅速做出原型，之后技术人员开发，如果3方脱节，项目开发会出现严重的问题，甚至失败。
    至于技术角度，一定要充分考虑系统的可扩展性和延续性，我已经遇到了非常多的这方面问题，例如很多系统在设计之初对用户注册系统考虑不周，导致用户名采用中文等特殊字符，这样就有很多问题，单点登录、Blog的二级域名处理、用户邮件帐号等等。
      

  5.   

    应该是显示层最麻烦，一个项目中最不同的就是view了，一个模块，你只要知道view的样式，还有所涉及到的表，就可以很容易的完成，因为，框架已经搭好，流程都一样，就是sql语句不太一样而已
      

  6.   

    应该是web层的开发量最大,
    业务层和DAO分离没有你说的那么难,关键是你自己和你的组员要有这中意识,设计的时候仔细的考虑就可以了.有时为了功能上的实现而忽视了这些东西的情况很常见
      

  7.   

    应该是web层的开发量最大,
    业务层和DAO分离没有你说的那么难,关键是你自己和你的组员要有这中意识,设计的时候仔细的考虑就可以了.有时为了功能上的实现而忽视了这些东西的情况很常见
      

  8.   

    孰不知web层的技术更新很快啊！孰不知web层的技术更新很快啊！
    孰不知web层的技术更新很快啊！孰不知web层的技术更新很快啊！
      

  9.   

    看来大家都已经公认了view层工作量最大了其实除了工作量之外,还有的就是view层的代码和可读性也很差,甚至有时一个页面上会有大量的js、java、xml等混淆在一起。个人认为这个问题更为重要，工作量大，但如果有了标准和规范，开发的工作量是大了，但在开发的过程中会感觉很轻松，而且后期维护也会很轻松希望大家能提出更多的问题和建议，回头再开个针对这些问题的解决办法的讨论
      

  10.   

    joincsdn(云) 
    的观点很正确，团队需要更多的标准和规范，做事才能有条不紊！！
      

  11.   

    j2ee技术交流群
    9438177
    欢迎朋友们的加入
    为的是探讨技术 呵呵
      

  12.   

    开发之前提前设计好吧
    分层分好  对开发人员严格要求  那一层该做什么比如  假如我用了 spring 
     那么分3层的话 view - contrl - dao 
    那就规定 view 只能做数据显示和表单录入
    ctrl 做控制dao
    dao 只能做数据库相关的如果view这一层与 ctrl 这一层的耦合之间有太多的业务逻辑
    那么可以再抽象出来一层  专门用来做 view 的数据准备在开发的时候，严格的按着规定走，一般应该没什么大问题
      

  13.   

    view是工作量最大
    但最简单吧
    当然不包括页面设计的
      

  14.   

    楼主显然把开发人员与设计人员的职责给混同了，你上面说的种种，都是设计的太烂，搞编码的也没有设计经验，好好的MVC框架就被搅在一起用了，思路乱啊
      

  15.   

    popularsong(甲虫)
    能说说你作为开发人员在开发的过程中或者时项目维护阶段发现的一些问题否?
    我的目的只是希望更多的人能提出更多的问题,或者在开发过程中的烦恼!
      

  16.   

    forandever(一打泡泡)
    "在开发的时候，严格的按着规定走，一般应该没什么大问题","应该"这个词我觉得不够实在,这是在理论的基础上进行推理得到的结果,很多时候还是要结合实践才能验证真理!
      

  17.   

    1  考虑过一个通用页面 一个统一的view,实现增删改查，
       基本情况如下： 使用js根据DTO或是Bean或页面上的From 来配置各个控件的状态(能不能修改，可见等等)，比如: CurrDto.currName:1:1:0:0  CurrDto.currName是根据Dto的属性命名的控件：比如文本框。后面4个数分别是在查增改删，下本控件的状态: 可见 可修改 不可见 等等
    初始化页面时根据操作给js脚本一个初试化的状态，然后js完成此状态下的各个控件状态的控制。  对于简单情况 基本实现。当然也有一些问题。
    2  不断的重构，填加东西的时候要有明确的规范，这个函数该在哪一层，见下一条。3  架构师在提出技术方案后，应该第一时间出台《编码与技术规范》，明确概念，统一实现和编码的细节。并且新人加入时，从此处入手。当技术更改导致规范变更时，不惜代价的调整所有的代码，再统一思想，继续开发。
      

  18.   

    个人理解 WEB 2.0就是以AJAX技术为领跑，以BLOG为代表的 新的编程时代，在这里我们会注重 CSS，AJAX，XML，JavaScript 及多种服务器技术，使得 表单提交出现了异步的可能，使得页面的提交可以局部化，从而减小了服务器端的压力，但由此也带来了 胖客户端的部分问题！
      

  19.   

    至于LZ说的MVC设计中 view占的工作量大问题，我想如果应用上现在的AJAX技术应该比较容易解决，可以借鉴GOOGLE的设计理念
      

  20.   


     添加 删除 修改 添加保存 修改保存  删除保存 全部跳转到一个action上，前台页面做一个隐藏类型，传过来认别。view 代码全部用jsp 写
      

  21.   

    个人设想:
    由于AJAX的出现,大家都被迫将目标转移到前台了,很多人都在javascript,xml,css,div,xsl等技术上困惑和徘徊,个人觉得如果能在前台AJAX和后台业务层之间能设计出一个通用平台,专门负责前台和后台业务处理之间的一个数据传输转换接口平台,这样更利于前台和后台的分工,减少前台和后台的耦合度,无需做后台开发的人员去考虑前台的javascript,xml,css,div,xsl等这些技术,将大家的思想带入混乱状态
      

  22.   

    个人认为：
    需求分析，系统设计都要考虑到他的灵活性！
    层次分明，结构清晰，定义或做好基本功能模块。注意模块的重用性和扩展性。
    其它模块完全可以模仿进行。至于通用页面 一个统一的view，本人认为还要慎重。
    一方面有悖oo，一方面复杂的交叉判断难以保证程序的健壮性。毕竟机器是通电的，也会出错。
    view层工作是程序员的基础，也是乐趣。如果哪一天变得像搭积木一样简单，后果可想而知！！