该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2004-06-22
age0 写道 怎么说好呢,我的整体设计概念是完全反传统的,对象的继承基本上是禁止的,对象之间只通过组合方式进行交互,所以不存在多态、扩展或设计模式之类的问题。
hi.age0,你目前采用的这种方法,的确比较新颖,我想知道我会在下一个项目中加以借鉴。我也不喜欢使用太多的对象,导致对象与对象之间关系过于紧密。
重构基本上只能由自己来做,不过因为系统对象数目不多,所以工作量不算太大,况且重构时经常要调整对象之间的协作关系,以更合理的方式重新划分职责,这些工作单靠工具是无法完成的。 测试确实是个大问题,因为在编译时无法进行,所以只能根据它们之间的依赖关系在运行时的部署阶段进行检查。 例如: Entity entity = new Entity("客户资料", "CustomerInfo); entity.AddColumn("帐号", "ID", "varchar"); Data customer = new Data("客户资料"); customer.entity = entity; customer.AddData("帐号"); // 如entity没有"帐号"则返回错误提示 事实上,Data 和 Entity 之间的关系是非常松散的,只有当两者拥有相同名字的元素时才会发生关联。为此,Data甚至增加了AddVirtualData()的方法,Data同样可以通过AddEntity()的方式增加多个关联实体,关键是ORMapping有能力自行处理多个实体之间的复杂关系。 |
|
返回顶楼 | |
发表时间:2004-06-22
to age0:
其实我最初的设计跟你的思想差不多,不过作为一个框架不只是完成一项功能那么简单,还要考虑到维护、重构等许多因素,你的方案没有考虑映射的问题,将数据库结构硬编码在程序中,这是个大家所公认的一个紧耦合问题。 |
|
返回顶楼 | |
发表时间:2004-06-24
我的目标没有那么伟大,只是想做一个简单易用的ORMapping机制而已。
数据持久化是非常讨厌的工作,虽然简单但是工作量不小,如果一张表有几十个字段的话,即使是最简单的增删改都会耗费很多无谓的人力资源去开发调试。 ORMapping的目标就是要让数据持久化工作对开发人员完全不可见,无论是谁在任何时候任何地方需要数据持久化,只需提供entity和data,无需配置,无需部署,ORMapping就会帮你解决烦恼。至于系统框架设计、模式或重构什么的,就顾不了那么多了,简单是唯一追求。 void button_save_click() { Entity entity = new Entity("客户资料", "CustomerInfo"); entity.AddColumn("帐号", "ID", "varchar"); entity.AddColumn("姓名", "Name", "varchar"); entity.AddPK("帐号"); Data customer = new Data("客户资料"); customer.AddData("帐号"); customer.AddData("姓名"); customer.SetData("帐号", TextBox1.text); customer.SetData("姓名", TextBox2.text); ORMapping orm = new ORMapping(entity, customer); if(orm.Insert() == true) MessageBox.Show("客户资料已保存"); else MessageBox.Show(orm.error); } |
|
返回顶楼 | |