侃一下关于程序的“柔性”

newkid

即使对C程序员，你这个代码也是很不友好的。比方你在DAU_init把DAU和一个结构挂上钩，随后的操作忽而是DAU忽而是结构，让人摸不着头脑。比如同样是写入数据操作，DAU_fromJSON(&sell_DAU,json)这是操作DAU, 后面的sell.stat=0又是对结构操作。sell_insert_dao(&sell_DAU,msg)乍一看和sell没有关系，谁会想到sell的数据最终要写到表里？data_init(&seat,SEAT_tpl)也是莫名其妙，照理说它应该被包含在DAU_init里面了。对sell也没见你调用data_init。
那么多地方调用DAU_free，这在PLSQL是完全不需要操心的，一旦结束调用资源就被自动释放或回收，才不会显得这么笨拙呢。
你最感到得意的地方就是sell_insert_dao之前的那几个赋值操作。这有什么了不起？如果用PLSQL来实现，你这个sell_app就是一个事务里面调用的子模块，它完全可以接受一个sell%ROWTYPE的参数。这种参数就是一个记录（类似C的结构），你可以只对其中几个列赋值，然后insert into sell values p_row_sell。
但是我还是建议写列名。当你发现表数据有错时，如果代码里有列名，你可以追踪到它是哪里来的。
估计你对DAU_copy(&sell_DAU,&ctx->ctx_DAU,0)也很得意，但在我看来很危险，因为你的“柔性”可能造成前面的数据被覆盖，仅仅因为字段名是一样的。

nannan5000

越看越晕了

newkid

杯具，闹了半天只有我看懂楼主的代码。

yulihua49

原帖由 newkid 于 2011-9-15 02:22 发表
即使对C程序员，你这个代码也是很不友好的。比方你在DAU_init把DAU和一个结构挂上钩，随后的操作忽而是DAU忽而是结构，让人摸不着头脑。比如同样是写入数据操作，DAU_fromJSON(&sell_DAU,json)这是操作DAU, 后面的sell.stat=0又是对结构操作。sell_insert_dao(&sell_DAU,msg)乍一看和sell没有关系，谁会想到sell的数据最终要写到表里？data_init(&seat,SEAT_tpl)也是莫名其妙，照理说它应该被包含在DAU_init里面了。对sell也没见你调用data_init。不需要加上也行。
那么多地方调用DAU_free，这在PLSQL是完全不需要操心的，一旦结束调用资源就被自动释放或回收，才不会显得这么笨拙呢。
你最感到得意的地方就是sell_insert_dao之前的那几个赋值操作。这有什么了不起？如果用PLSQL来实现，你这个sell_app就是一个事务里面调用的子模块，它完全可以接受一个sell%ROWTYPE的参数。这种参数就是一个记录（类似C的结构），你可以只对其中几个列赋值，然后insert into sell values p_row_sell。
但是我还是建议写列名。当你发现表数据有错时，如果代码里有列名，你可以追踪到它是哪里来的。（可以在日志中找到完整的sql语句，如果出错还有绑定变量值和错误信息,（粘到sqlplus里就可以执行））
估计你对DAU_copy(&sell_DAU,&ctx->ctx_DAU,0)也很得意，但在我看来很危险，因为你的“柔性”可能造成前面的数据被覆盖，仅仅因为字段名是一样的。你可以不用

DAU本来就是SRM，结构关系映像，你当然用的是结构，DAU只是做一个操作，帮你存取数据，不仅映像到数据库，同样映像到JSON，字符串等等。它只解决某种数据对象装入结构或把结构内容打包到其他数据对象。需要读者理解这个概念。


C的内存不能自动回收，这不赖我。恰恰是提供了这种类似析构函数，还有使用规范（文档里有），使得即使新手都能写出内存安全的应用。
内存自动回收是双刃剑。在大型多线程服务器里引起不确定的结果，由于线程互斥造成互相等待，这在JAVA里表现明显。不是咱们的话题，不多说了.

前端传来的大批列，如何向记录赋值？最后的结果还要传回客户端，如何取值到通讯包？
如果使用PRO*C，光就这个sell表，看看得写多少遍列名:
1.declare 1遍
2.从json赋值，2遍（等号左右各一遍）
3.如果是varchar2型，计算长度一遍。
4.into后边列名 一遍
5.values，绑定变量 一遍。
6.打包输出一遍。
没算真正业务逻辑那几个赋值。这大概几百行了吧？
楼上一位朋友说没看懂，写上这几百行就看懂了吗？你是因为业务不懂，而且C不熟。如果几个表的SQL都写出来，几千行，完全淹没了业务逻辑。（我要是真把几千行的程序摆在这，恐怕你连看也不看了）
有看几千行代码的精力，用来学习一下业务逻辑是否更有意义？

另外，从80列到150列，不是一次，而是n次逐步的，你改这几千行代码，不辛苦吗？

[ 本帖最后由 yulihua49 于 2011-9-15 11:20 编辑 ]

newkid

事务的接口必须是静态的。我不相信你一下子会传进来150列，很多应该是计算出来或者从其他表获得的。需求有变化，表结构修改、客户端修改、接口也要相应修改。我不认为这有什么难的，特别是你增加的数据只是简单保存起来，不参与计算。
如果你的程序允许接收任何字段，这里面有安全隐患。我的事务接收什么数据必须是已知的、能静态编译的。
就像那个DAU_copy，我的灵敏嗅觉一下子警惕起来，而你这方面的修炼显然还不够。

〇〇

原帖由 newkid 于 2011-9-15 09:21 发表
杯具，闹了半天只有我看懂楼主的代码。

本来就是

newkid

原帖由 〇〇 于 2011-9-16 04:46 发表

本来就是

他贴出来本来是想让大家肯定他的代码的可读性，但不幸的是只有他的老对手读懂了。

nannan5000

原帖由 newkid 于 2011-9-16 05:21 发表

他贴出来本来是想让大家肯定他的代码的可读性，但不幸的是只有他的老对手读懂了。

老话怎么说的来

最理解你的是你的对手~

yulihua49

〇〇 发表于 2011-9-16 19:17
#159
使用道具  
发表于 2011-9-15 09:54   

他贴出来本来是想让大家肯定他的代码的可读性，但不幸的是只有他的老对手读懂了。



首先感谢你，为我保存了这些帖子。

其二，这里，你们似乎都是SQL大师，似乎C不太熟了？结构化过程语言读不懂？
再者，这是一个铁路售票记账程序，newkid以前探讨过。就这几行程序都不懂，我要是列名列出，2000行就能懂了？
80or150列，确实是前端传过来的。通过之前的客户输入一部分，席位查询一部分，交易调整，票价计算，支付处理。。。。合成了这些数据，通过一个JSON包传过来的。JSON的处理，你们可能不熟，但没有关系。
DAU_fromJSON(&sell_DAU,json,0); 不知干啥的？不要管。知道这一步JSON的数据进入了DAU就可以了，管它是80个列（对象）还是150个，管它是哪些列呢？反正JSON对象名与模板列名相同的就转过来，这是设计好的接口协议。如果有什么问题，日志里可以看到可以分析，容易改正。

原来的帖子不太好找了，补在这：

前端传来的大批列，如何向记录赋值？最后的结果还要传回客户端，如何取值到通讯包？
如果使用PRO*C，光就这个sell表，看看得写多少遍列名:
1.declare 1遍
2.从json赋值，2遍（等号左右各一遍）
3.如果是varchar2型，计算长度一遍。
4.into后边列名 一遍
5.values，绑定变量 一遍。
6.打包输出一遍。
没算真正业务逻辑那几个赋值。这大概几百行了吧？
楼上一位朋友说没看懂，写上这几百行就看懂了吗？你是因为业务不懂，而且C不熟。如果几个表的SQL都写出来，几千行，完全淹没了业务逻辑。（我要是真把几千行的程序摆在这，恐怕你连看也不看了）
有看几千行代码的精力，用来学习一下业务逻辑是否更有意义？

另外，从80列到150列，不是一次，而是n次逐步的，你改这几千行代码，不辛苦吗？



这N多的列（席位的列，存根的列，甚至其它表的列，都在一个JSON包里），如何交待给存储过程？有何高招？

nannan5000

yulihua49 发表于 2011-9-17 16:31
他贴出来本来是想让大家肯定他的代码的可读性，但不幸的是只有他的老对手读懂了。

期待Newkid的 回复~