艰难的抉择--请大家赐教

博客专家认证

2011-08-02 04:51:51

公司的ERP系统（实际规模比ERP大，还包括CRM,PLM),想采用ADO.NET Entity Framework来做数据访问及持久层，这段时间都在对AEF进行了解。AEF的一个好处就是对于不同数据库可以透明支持(其持久层功能对于业务系统来说没有多大的实际意义),如果仅仅是因为它的名头和不同数据库透明支持，感觉不是很好，因为对应的ObjectContext分割比较困难，不分割吧，这么大的系统（表数量至少在2000以上）也不现实，分割吧，ObjectContext之间的实体关联查询又会有问题。而且Insert,Update,Delete都没法用，只有采用框架提供的功能，遇到统计，分析等功能难道也要对着一堆实体进行？

现在感觉AEF基本就是个内存关系数据库了，我们本来就是选用的关系型数据库，为什么又要用这个呢？

AEF看起来确实简单好用，但我觉得这么大的系统能否胜任，心里没底，请问大家，有谁用这种框架做过大型系统么？

请大家说说，谢谢！

...全文

146 12 打赏收藏转发到动态举报

写回复

用AI写文章

12 条回复

切换为时间正序

请发表友善的回复…

发表回复

以专业开发人员为伍 2011-08-04

打赏
举报

对于一个一个颗粒度的业务功能方面，都是在编码之前有任务规划过程的。比如不涉及界面开发的方面，通常可以在二十分钟小时到一个小时内解决。现在假设一个人写的代码它在测试上没有问题，那么你就无需去修改。假设在测试上有bug，而你懒的去修改它的代码，那么你大不了去删除了他的源代码而重写就好了，用不着去调试那些用你不喜欢的方式写出来的代码。

能够做到这些，依赖于迅速确认，依赖于测试驱动开发。作为主管不是整天研究什么编码“规范”或者“算法”这类所谓的技术，而是应该去研究和掌握那些迅速自动化地协调项目进度的技术（工作10年以下的程序员几乎不可能很好靠看书就理解这些技术的价值）。

以专业开发人员为伍 2011-08-04

打赏
举报

所谓“艰难”，往往伴随着这种作坊特色：

花大量时间纠结于具体的编程格式，只有粗粗的用户界面分解而没有明晰顺畅的任务迭代计划，发现bug时总是让原来写这个代码的人自己去修改而不是集体所有代码（任何人都可以修改别人的代码），代码改动之后没有经过自动化测试就轻率地提交给版本管理系统。

项目管理方法越是乱，越是纠缠于官僚格式。唉！

以专业开发人员为伍 2011-08-04

打赏
举报

你愿意用就用，不愿意用就不用。对同一个项目中的别人也是如此。不要先入为主地搞什么“只许用什么什么，不许用什么什么”这种论调。有的人觉得sql好，就用sql；有的人觉得orm好，就用orm；有的人觉得linq to ef好，就用它。关键是所有代码都要经过高强度的自动化测试，有一点bug都不能带着问题继续开发。假设有些人选择了很慢的开发方法，或者不容易自我调试的开发方法，那么他的许多任务都会因为超时（比如评估为5小时的任务结果8小时还没有完成）而取消，他写的代码也就作废了，而让别人去写。这样有些人慢慢地就会向更实用的开发方法靠拢，也就不认为越是低级的东西越好了。

lllcui 2011-08-04

打赏
举报

统计，分析可以用存储过程和视图来解决。框架会自动生成

娃都会打酱油了 2011-08-04

打赏
举报

何必呢。。何苦呢。。。。还是自己写SQL吧。。。。。
要毛个ORM。。。。这东西也是裹脚布。。。。裹得很快，解得很慢。。。。。

lijie_255456 2011-08-04

打赏
举报

不太懂！学习！

广州接入 2011-08-04

打赏
举报

首先谢谢sp1234的回复，我还没有这么霸道的去说让用与不让用，但我们是做产品，不是做项目，最终统一是肯定的，不会每个人都用自己的一套。但在这个决定之前，还是需要充分讨论的。我的感觉其实是微软的东西在这种应用框架上变化太快，原来是一种模式，现在又提供另外一种模式，而另外一种模式的提供就是为了解决原来模式的一些问题，不是很好跟随。与其这样，我们不如采用我们认为比较方便的方式进行处理，把关注点从框架技术转移到我们的业务实现上来。虽然AEF提供的功能很好，但比起我建议的方式来讲，还是慢很多，因为基本的业务层功能和以下的层大绝大部分东西可以像AEF一样可以自动生成。

对于规范和算法，一个方面，我认同你的观点，我觉得学会抄就可以了，但另外一个方面老板喜欢这些，不学点也不现实。

广州接入 2011-08-03