青林园

123

xml存储数据

[quote]青林一霸： @走来走去 这个标准我有，我有到村和居委会的数据。但我是想将我现在设计的行政区类能用到多个地方，比如联系人里的地址，ArcGIS中的点或块，所以想设计成一个强大的类，可能有些偏执了。[/quote] 分析一下这些数据 貌似其实都是一样的? 或者可以抽取出一样的部分形成一个类,树型 数据库里是一个表 在这个基础上再继续研究

@枫 @锦瑟 @金旭亮 看来我又要学习新的知识了，我总是在找解决方案的过程中学习东西，技术是了解了一些，问题还没解决过。 不懂的地方，还请金旭亮同学指教

@走来走去 这个标准我有，我有到村和居委会的数据。但我是想将我现在设计的行政区类能用到多个地方，比如联系人里的地址，ArcGIS中的点或块，所以想设计成一个强大的类，可能有些偏执了。

@Vincent Yang 正好你所说，“你所提出的问题就像是一个四不像的东西......”，我前面已经说明了我的情况，毕竟不是科班出身，也没有工作压力，自学编程搞的四不象，其实我都自行惭愧了，搞了这么长时间，一点成果都没有，整天追求新术，都一大把年纪了..... 如你所说，我对Domain Driven的原理最多只是字面意思上的理解。其实我开始倒没有考虑数据的问题，图也是今天才画的，我的类早就设计好了，只是到后来想用Linq to SQL时，发现所设计的类间的逻辑关系没办法用关系型的数据表很好的表现出来，于是才想在设计类时也要考虑持久化的问题。当然了，我直接写SQL查询语句我也会一些，反正不是产品，自己用用。但我有个想法，懒人创造新办法的动力。由于我想懒一下，想找个很酷，很快捷，很通用的办法。于是我就陷于其中，就有了今天的烦恼..... 感谢大伙的评论，给了我不少认识事务的角度。

ado.net entityframework 可以解决你的问题，行政区这样的用TypeOf<>就可以知道其具体类型。

感觉第一个图的设计不伦不类的，我觉得你首先要确定你要从domain centric下手还是从data centric下手。从你的意思，我感觉你想从domain centric开始，但是你并不了解domain driven的原理，所以你所提出的问题就像是一个四不像的东西。一会database关系，一会class 如何映射到数据库，这样是不行的。从data centric转换思路到domain centric要花很多精力去理解的，和关系数据理念几乎完全不一样，并不是你说的"最新最快捷的技术"。

关于县市级别的类似问题，建议可以先捋顺正常的层级关系，然后一步一步重构成可以兼容异常情况的，这样比较好，不要一上来就考虑异常情况，那样你的工作就没有办法开展了，是不是呢？ 还可能走歪呢？可能考虑了很多，都是没有用的？

楼主的这个问题是非常典型的面向对象设计问题。有N种解决方案。比如可以使用接口，可以使用抽象类，可以使用一个类工厂根据参数来创建不同类型的对象…… 有一个设计思路方案不知楼主想到过没有？使用“泛型+接口（或抽象类）”。我在.NET Framework中看到过不少这种设计方案。 比如在WF4中，工作流中有一个抽象类CodeActivity，然后微软又加了一个CodeActivity<T>作为其子类，用户自定义的Activity派生自这两个类之一。在WF中，所有的Activity都可以被序列化为XAML字串。 模仿这种设计思路，你可以把所有对象序列化为XML，然后保存到数据库，定制一个类工厂（不妨取名AccountFactory），将某个XML字串传给它，由它向外界返回合适类型的Account对象就可以了。

中国的行政区划有国家标准GB T 2260-2002 那里面定义的结构很清晰，你去搜一下即可 不光是行政区 包括 民族 国别 职称 行业 等都有相应的国家标准，你找找，直接用这种是最省事的，一串数字就可以得到行政区的所有信息

纯对象来说，行政区域的划分应该算是一个组合模式的例子，因为其本身就算是一个树形。 ORM都必须要有额外的存储来标记对象的类型，这是对象的三维性质决定的。NH中是xml-mapping，XPO中是另外一个表，至于具体怎么做每个工具都不同吧。

有点乱啊

[quote]民工精髓：行政区划直接自关联，多加个字段用于描述它是什么级别即可[/quote] 基本赞同这个建议

行政区划直接自关联，多加个字段用于描述它是什么级别即可

@Ivony...[quote]Ivony...：http://www.cnblogs.com/Ivony/archive/2008/08/14/1268262.html[/quote] 看来，不只是我有这样的烦恼啊！ 其实对于这个问题，我们亲爱的Bob大叔好像也只是找了个不是很漂亮的办法。参见《敏捷软件开发：原则、模式与实践C#》 做法是这样的：在我的场景中，他采用的就是第二种设计。Account类对应Account表，然后设计一个AccountCategory类，Account拥有AccountCategory类的属性，Account表中Category字段填写类型名称。CreditCard等类继承自AccountCategory并各自设计成一个表，并关联到Account表。 Bob大叔的数据存储与取出都是自己写的代码直接操作数据库，不是很自动化。我这样，是不是我太偏执了呢？

如果没有特别需求，地区不用分级，设计成自关联的表就ok了。属性不同的，归纳一下，做不同的属性表就可以了。楼主碰到的问题是数据库设计的问题，不是类设计的问题。

@迭戈_Forever 能实现这样的逻辑吗？

用NHibernate实现吧

这。。。。。