NHibernate in Action: write POCOs【Association】【2】

在这里实现上两次提到的模型中的代码，依据的图是如下的图：

由于作者并没有提供详细的业务类的说明，这里仅仅根据这张图构建出来相关的Model，然后在根据昨天提供的源码一步步地的细化。

说明：

         1. NH要求提供默认的构造函数，这里明确一下每个类都添加这样的构造函数。

         2. 不在代码中写明白每个类的其他构造函数，比如XXXClass（ParamterA, ParameterB, ParameterC);

     这次需要将上图中提到的各种关系表达出来，关系的构建需要考虑两个方面：

• 数量关系。考虑对象之间的数量关系，决定是一对多还是多对一或者多对多的关系。
• 双向关系。 是否需要构建双向的关系。
• 维护关系。 构造维护双方的关系。

【注】此处参考NH In Action 的源码

Address

    [Serializable]
    public class Address
    {
        public Address() { }
        public string Street { get; set; }
        public string ZipCode { get; set; }
        public string City { get; set; }
    }

说明:

• 此处不考虑从Address中获取User的信息。

BankAccount

    [Serializable]
    public class BankAccount: BillingDetails 
    {
        public BankAccount() { }
        public string BankName { get; set; }
        public string BankSwift { get; set; }
    }

说明:

• 从BillingDetails继承下来。
• 业务意义上应该是付款-银行方式。
• 由基类BillDetail来处理和User的关系，此处不需要。

CreditCard

    [Serializable]
    public class CreditCard: BillingDetails
    {
        public CreditCard() { }
        public int Type { get; set; }
        public string ExpMonth { get; set; }
        public string ExpYear { get; set; }
    }

说明:

• 从BillingDetails继承下来。
• 业务意义上应该是付款方式--信用卡方式
• 由基类BillDetail来处理和User的关系，此处不需要。

BillingDetails

    [Serializable]
    public class BillingDetails
    {
        public BillingDetails() { }
        public string Owner { get; set; }
        public string Number { get; set; }
        public DateTime Created { get; set; }
        public User User { get; set; }
    }

说明

• CredtCart和BankCount的基类
• 业务意义上是付款方式。
• 被User所引用，此处构建一个双向的关系。

User

    [Serializable]
    public class User
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string UserName { get; set; }
        public string Email { get; set; }
        public int Ranking { get; set; }
        public DateTime Created { get; set; }
        public Address HomeAddress { get; set; }
        public Address BillingAddress { get; set; }
        public IList<BillingDetails> DefaultBillingDetails { get; set; }
    }

说明：

• 聚合了一个Address类，所以不是集合形式的。
• 有一个或者多个BillDetiails， 所以是IList形式的。默认名字为DefaultBillingDetails。
• 说明一下：作者把之前的BillDetail类命名为BillDetails，而且是Abstract的，感觉不大合适，这里修改过来。
• 有两个Address。 HomeAddress和BillingAddress。

Category

    [Serializable]
    public class Category
    {
        public string Name { get; set; }
        public Category Parent { get; set; }
        public IList<Category> ChildCategories { get; set; }
        public IList<Item> CategorizedItems { get; }
    }

说明:

• 由于是自我聚合的，所以存在一个指向父的Parent属性。存在一个指向自己的ChildCategories的属性，指自己所包含的所有的子。
• 除了自身的业务之外，还增加了一个CategorizedItems属性，表示所有关联的Items。

Comment

    [Serializable]
    public class Comment
    {
        public int Rating { get; set; }
        public string Text { get; set; }
        public DateTime Created { get; set; }
        public User FromUser { get; set; }
        public Item Item { get; set; }
    }

说明：

      1。Comment是属于某个User或者Item的，和这两个的关系是零对多的关系。
        2 。User命名为FromUser。

Bid

[Serializable]
    public class Bid
    {
        public double AMount { get; set; }
        public DateTime Created { get; set; }
        public User Bider { get; set; }
        public Item Item { get; set; }
    }

说明：

       1. 代表了最终竞拍的价格和标的。

        2. 和User， Item的关系都是零对多的关系，这里临时拉过来这两个对象。
        3。基本上没有什么变化。

Item

  [Serializable]
    public class Item
    {
        public string Name { get; set; }
        public string Description { get; set; }
        public double InitialPrice { get; set; }
        public double ReservePrice { get; set; }
        public DateTime StartDatetime { get; set; }
        public DateTime EndDatetime { get; set; }
        public DateTime Created { get; set; }
        public User ApprovedBy { get; set; }
        public User Seller { get; set; }
        public IList<Category> Categories { get; set; }        
        public IList<Comment> Comments { get; set; }
        public IList<Bid> Bids { get; set; }
        public Bid SucessfulBid { get; set; }
    }

说明：

      1.  是一个User买的，所有增加了一个Seller的属性。

        2.  属于零个或者多个Category, 拥有多个Comments或者Bids所有加入了三个List的属性。
       3。没有太大的变化，加入了被那个UserApprover的，最终的Bid的因素。

总结一下：这里的Action基本上都是双向的，也就是每个里面都可以任意的获取另外一个元素。除了某些部分比如说Address等这些不是业务的中心类外，其他的都是。整个关系基本上就是这样的。

另外作者用的多数是ISet，这里用的是IList，需要对比一下这两处的区别。