|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：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); } |
| 返回顶楼 | |
