与项目经理思路冲突，项目经理说一定要按他的方法实现，真不能理解，请大家帮帮忙

本帖最后由 woshikaka6 于 2014-04-19 19:53:35 编辑

解决方案 »

  1.   

    我说，你在sql里面改其他人怎么能看的懂，我在代码里更改加个注释谁都可以看得懂。
    这句说不过去，代码能加注释别人能看懂，SQL语句一样能加注释别人也能看懂。
      

  2.   

    你们项目经理是傻逼，底层应该忠实的向上层反馈最原始的数据，由上层进行对数据的简单处理，再由上上层进行更为复杂的处理，以此类推。在这里就是dao层返回原始的a b，校验、互换什么的，上层去做。
      

  3.   


    我的思路是这样的：java程序员是面向对象编程的，如果有一个需求变化都跑到dao层去改sql语句那不是很麻烦，你也知道真实开发中sql语句是非常恶心的，都是一串一串拼接起来的（用Spring的jdbcTemplate）。
      

  4.   

    不能这么想，真正得SQL编程很牛的，不是90%程序员看到得那样，SQL得功能非常强大，很多东西在SQL处理比应用层效率高很多。
      

  5.   


    我的思路是这样的：java程序员是面向对象编程的，如果有一个需求变化都跑到dao层去改sql语句那不是很麻烦，你也知道真实开发中sql语句是非常恶心的，都是一串一串拼接起来的（用Spring的jdbcTemplate）。
    如果有一个需求变化都跑到dao层去改sql语句那不是很麻烦
    同样的思路，需求变化了同样得改代码。
    改SQL也是改，改代码也是改，而且未必差距会有多大。
    对与这种不值当得问题，没必要争的头破血流，顺着老大就是了。
      

  6.   


    我的思路跟你差不多的，我是想我们是面向对象的程序员，java类跟表属性就是要一对一匹配映射，我们不要动不动就去改映射关系，后面属性值要进行对调，就是要在业务层里面进行对调赋值，然后再加个注释，不是很简单明了。我项目经理一定要我从dao层去改
      

  7.   

    不能这么想，真正得SQL编程很牛的，不是90%程序员看到得那样，SQL得功能非常强大，很多东西在SQL处理比应用层效率高很多。
    就是因为程序员是面向对象编程，而sql是面向关系模式，遇到问题就要用程序员的思考方式去解决问题，如果都是sql去解决那我们程序员不就违背了面向对象初衷？
      

  8.   


    底层应该忠实的向上层反馈最原始的数据，这是一种编程思路，我想请教你一下，你这个编程思路是你自己总结的吗？
    这种说法很荒谬。
    看来你和那项目经理一种智商
    孩子，去了解下复杂的数据情况，几十到上百个表联合查询的业务多了去，而且SQL里也要处理一些既定业务逻辑，看看存储过程之类的。
    要是你都把最原始的数据给上层，你想过数据库的压力感受吗？想过网络的感受吗？你这么叼你家人知道吗？
      

  9.   

    只有DBA才会认为存储过程比程序更适应复杂的情况，我想你们项目经理本来是个DBA吧，根本不懂什么叫做面向对象。
    如果你有一个好的架构支持，SQL字段名称根本不重要，因为那是透明的。
    我想问问那个DBA：在程序中交换两个值，在哪里增加了数据库压力？与网络有什么关系？真会扯淡。
      

  10.   


    底层应该忠实的向上层反馈最原始的数据，这是一种编程思路，我想请教你一下，你这个编程思路是你自己总结的吗？
    这种说法很荒谬。
    看来你和那项目经理一种智商
    孩子，去了解下复杂的数据情况，几十到上百个表联合查询的业务多了去，而且SQL里也要处理一些既定业务逻辑，看看存储过程之类的。
    要是你都把最原始的数据给上层，你想过数据库的压力感受吗？想过网络的感受吗？你这么叼你家人知道吗？
    笑了，我说的是这种情况吗？联合查询，处理逻辑业务，为的是要获取符合条件的数据，你直接把数据给置换了，人家看到从数据库里取出的数据跟字段名对不上，考虑过人家维护人员的感受么？还是说，你们开发根本就不分层，或者表面上看做了分层，其实完全就是做做样子，从业务代码到sql'都糊成一团？你这么吊，你项目经理知道么？
      

  11.   

    这个真被你猜中了，我项目经理就是偏向dba，为了显示权利在他手上，所有业务的字段跟表结构修改都必须经过他手。我很想跟项目经理说：现在数据层框架这么发达，用一个实体类完成映射，就是1分钟的事情。
      

  12.   

    我那项目经理真的有点sb，你说的道理我明白，但是有一个sb经理真的不懂java技术，天天教你怎么写java。打个比方：为了赶时髦，项目装了jdk1.7，然后编译器用1.6，项目报编译异常却不懂是什么原因。
      

  13.   

    嗯，这个比较靠谱，动不动和领导对着干，那不是给自己找不痛快嘛，在说，按照楼主描述的这个问题，sql里面取个别名也没什么不可，何况代码里面去互换下不是又要多遍历一次，或者显示的时候页面上把A显示为B的数据，B显示为A的数据一个交叉互换而已，不会遍历也不会产生真正的互换，不明白楼主为何一定要纠结这么个简单的问题，还上升到了面向对象和面向关系的优劣高下的高度，是否有点过于吃毛求疵了。
      

  14.   

    个人感觉是用SQL来互换比较好，效率也高
    假如你获取列表有1000条数据，你要在业务里循环1000次来对调2个属性的值
    如果是SQL就直接加个别名可以了
      

  15.   


    你误会了，我从来没觉得我很牛逼，相反，我一直觉得我基础不够扎实，现在还在不断学习javaSE基础知识。我的初衷想法非常简单：我只是从我的角度出发说出我的想法，你为什么连这种想法都不允许我说出来，如果全部都要按你的技术实现走下去，我留下来有什么用？那我只是打字员。你找一个刚毕业的学生不是更适合这位置。我刚提出我的想法，不到30秒就直接被吼下去了。
      

  16.   

    原来DBA是这样写程序的哦，难怪了。
      

  17.   

    原来DBA是这样写程序的哦，难怪了。真的怀疑这样的DBA写出的SQL语句回事怎么样的。
      

  18.   

    你们这吵来吵去的，还没改到重点啊。这种东西要改彻底点，弄个歧义的东西放在代码里算么斯？“属性a要显示列名b的内容，属性b要显示列名a的内容”
    直接把数据库的列名改了！！
      

  19.   

    如果是我们现在的框架，毫无疑问采用的项目经理的这个方式
    因为改动最少，只需sql中列出别名，不需要改动后台代码；在部署的时候sql只需要覆盖，不需再编译。
    从这些角度上来说改动最少，速度最快。我记得我有个同事说过，如果有冲突时你可以用你的想法去说服别人，如果说服不了，那就要考虑哪种情况更好。