可用分有7000多了,准备散掉,讨论一些日常开发中经常遇到的,有争议的问题,希望大家踊跃发言,并欢迎各路高手指点迷津!每个问题100分,给发言最精彩的5个人。第三个:企业应用经验交流(zeusvenus)请大家说说自己在开发企业应用时的一些经验,比如安全性、数据缓存、架构设计等等...

解决方案 »

  1.   

    企业应用常常还需要考虑SSO,组织结构共享等应用集成、整合问题。下面这段不算广告吧,^_^
    欢迎大家来我的博客作客:http://blog.csdn.net/aafshzj/
    我正在写一系列关于AAF组件框架的文章。该框架能对开发工作提供很多帮助,并极大地提高开发效率。希望大家看一看并提出宝贵建议。
      

  2.   

    经验谈不上,我谈谈未来某天即将失败的案例吧
    以实例说明
    开发商:某公司(该公司在我公司从事的行业中长江以北占有90%的市场份额,长江以南目前没有市场)
    客户:我所在的公司,也就是说别人给我们开发的一套MIS(开始是按ERP在全公司公宣传的,最后开发商自已定位到MIS了,反正企业的高管和大部分员工不懂ERP和MIS有什么区别)1、安全性:国际上先进的加密算法,一个都不用,保存数据库连接串在一个二进制文件中用在char[i]中进行加减法运算,我们公司5分钟内就得到了访问数据库的了这个串的算法,而且这个串是用SA用户登录的,在座的可能比我还消楚SA的权限有多大?这个权限被有想法的人知道后会带来什么后果;操作员身份验证,是下了点辛苦,不过也没用什么先进的加密算法,不过还是用了一晚上才搞清楚了用户口令加解密的算法.而且整个软件过于依赖SQL语句,实际上,几个月时间,我们通过跟踪模版,彻底摸清楚了他的数据库结构和软件运行逻辑,重写一个同样功能的完全没问题.
    2、数据缓存,这家公司没有这种概念,在他们心里,数据永远是动态的,缓存随时都是过时的.
    3、架构设计,整套软件的架构我评0分.实际上根本不存在什么架构思想,整个数据库一共200个表(就是这个数,一个不多一个不少),存储过程8个(挺吉利),前日讨论的数据库高级特性,一个没用(我们有同行业中应用该公司这套软件的另一家企业的在2004年请微软公司鉴定过这个数据库的设计,最后给了两个评价,1、数据库的索引建得不好。这点我们也看了,每个表大约都有8-9个索引,不过查询跟踪踪模板中执行的SQL语句中,我实在是看不出这些索引那个能被查询所应用;2、微软自己承认SQL Server不适合我们这个行业的企业应用,这个结论是在是让我们无法再去厚非这家公司),个别表连主键都没有,中间层不存在,实际上整个应用就两层,而这套系统,现在大约有103个网点客户端(工作站)同时工作,估计这个月如果和几家银行商量好的话,可能客户端会增加到500多个,而且他们没什么设计思想,对待问题的做法就是每出现一个新的需求,在现有的设计上采用打补丁的方式处理......调研初,和对方商议,需要写三个现有三套系统做的接口,目前为止,三个接口全都无法实现.可怜打印机和工人,像网线一样每天负责在几套系统间交换数据......
    我一共搞了八年的开发(我是搞本企业内的应用开发的,一般开发的内容不上市场),当看到一个别人给自己所在的企业开发的软件是这种状态时,心中实在是不是滋味.现在这个年代,也许是客户容易被骗,或管理体制的漏洞太多,也许是幕后有什么黑暗交易,看到这种状况,就算我心急如焚,也胸无一策.
    我说的全是牢骚话,不知道我所谈的安全性、数据缓存、架构设计和楼主想讨论的主题是否一样,不过我希望这个案例能成为在座纭纭高手门的一个反面素材。
      

  3.   

    不论是大江南北、国内国外,将终端网络的维护部署工作减低到为“零”,当属web架构。除非非常高级的应用一定要使用p2p结构,否则大部分可以使用Ajax来解决。我开始学习Ajax时的第一个测试程序的例子: http://cqbd.gnway.net/AjaxDemo/
      

  4.   

    楼主这几个讨论很有价值。
    说说我的拙见:
    企业应用和平常小系统不同,由于承担较重的责任,所以安全性要求一般比较高,尤其是对公众服务的应用一定要做好异常处理。另外一个要重点考虑的是与原有系统的整合、沟通,现在一些企业终于真正关注起SOA来了,不像原来只是观望着喊口号;而内部应用往往做得比较平台化,这对架构提出了一些特定的要求,一般一个平台要能承载多个业务并要为扩展可能出现的业务留好接口,这直接导致多层架构、分析模式应用和组件设计的参与。我们.NET阵营在之前这方面做得不够好,需要加把劲。
    数据缓存方面我倒觉得并无过多特殊之处,平常任何一个应用都要考虑性能的,企业应用开发概莫例外。楼下接上。