.NET Tools 2005--小气的神

#1楼 2004-07-25 09:52 progame

楼主给出的链接中好像也不全是开源的
那么我再给几个相关：
DataObjects.NET
EntityBroker
LLBLGenPro
Grove

在我的概念中，CRUD是一定要交给EntityManager去做的，但OQL我是执观望态度的，lazy-loading、object cache、relation mapping这些我宁可用相关的替换方法去实现，因为我希望不管是使用者还是开发者，都尽可能简单。如果ORM让你的数据管理反而更复杂，那么我还不如直接写SQL了，所以我自己的ORM定义是比DAL功能多一些，但比标准的ORM定义功能少一些。

还有就是dabatase->class or class->database，我是倾向于前者的，可能是因为我之前做的MIS，所以更容易用关系数据库去思考问题。   回复  引用    

#2楼 2004-07-26 06:18 lonelystranger[未注册用户]

老大好久没来了   回复  引用    

#3楼 2004-07-26 12:16 ccBoy

别这么说:) ，争取有时间就来   回复  引用    

#4楼 2004-07-28 09:03 lonelystranger [未注册用户]

I see   回复  引用    

#5楼 2004-08-07 17:05 sunmast[未注册用户]

hi, ccboy
这里还有一个ORM工具~
http://blog.sunmast.com/Sunmast/archive/2004/08/07/817.aspx   回复  引用    

#6楼 2004-08-12 14:49 仪表[未注册用户]

Visio2003里面提供了一个，比起上面的有什么区别阿？   回复  引用    

#7楼 2005-02-20 00:00 piggybank[未注册用户]

非常赞同，我也持相似的意见:

>如果ORM让你的数据管理反而更复杂，那么我还不如直接写SQL了，所以我自己的ORM定义是比DAL功能多一些，但比标准的ORM定义功能少一些

ORM，AoP 也好，Code Generation也罢，我并不期望能够100%起到作用。就好比一个产品的诞生和完善一样，这些概念或者相应软件的完善也是需要一个过程的。
而恰恰是这一点，最重要：因为我的 Team 的建设，Team 中每一个成员的成长也是同样的过程。
因此，讨论需要继续，但等待或者不停地选择，会浪费很多时间和精力。更重要地，我认为哪怕没有结果，但能够在思维过程中得到收获，意义远远大于节省了人力。

何况，ORM，或者说不彻底的ORM，以及Code Generation对我们的开发工作还有一个很重要的意义：约束、规范，并减少不一致性。   回复  引用    

#8楼[楼主] 2005-02-21 14:55 ccBoy      

多谢piggybank ，你能使用技术之外的眼光看待这个问题。
我认为颇为实际和考虑现实情况   回复  引用  查看    

• 我的参与
• 我的新闻
• 最新评论
• 我的标签