Overly accessible and incredibly resource hungry relationships between business objects.我该如何解决这个问题？

Question

首先，这似乎是一个很长的问题。我不认为这是......代码只是我当前正在做的事情的概述。这感觉不对，所以我正在寻求建设性的批评和对陷阱的警告以及我能做什么的建议。

我有一个包含业务对象的数据库。
我需要访问父对象的属性。
我需要通过业务对象维护某种状态。

如果您查看这些类，我认为访问修饰符不正确。我认为它的结构不是很好。大多数关系都是用公共属性建模的。 SubAccount.Account.User.ID <-- 所有这些都是公共的。

是否有比这更好的方法来建模类之间的关系，使其不那么“公共”？

这个问题的另一部分是关于资源的：

如果我要创建一个返回列表的 User.GetUserList() 函数，并且我有 9000 个用户，当我调用 GetUsers 方法时，它将创建 9000 个 User 对象，并且在其中将创建 9000 个新的 AccountCollection 对象。我该怎么做才能让这个项目不那么消耗资源？

请找到下面的代码并将其撕成碎片。

public class User {

   public string ID {get;set;}
   public string FirstName {get; set;}
   public string LastName {get; set;}
   public string PhoneNo {get; set;}

  public AccountCollection accounts {get; set;}

  public User {
     accounts = new AccountCollection(this);
  }

  public static List<Users> GetUsers() {
     return Data.GetUsers();
  }

}

public AccountCollection : IEnumerable<Account> {
  private User user;

  public AccountCollection(User user) {
     this.user = user;
  }

  public IEnumerable<Account> GetEnumerator() {
     return Data.GetAccounts(user);
  }
}


public class Account {

   public User User {get; set;}  //This is public so that the subaccount can access its Account's User's ID
   public int ID;
   public string Name;

   public Account(User user) {
      this.user = user;
   }

}

public SubAccountCollection : IEnumerable<SubAccount> {
  public Account account {get; set;}

  public SubAccountCollection(Account account) {
     this.account = account;
  }

  public IEnumerable<SubAccount> GetEnumerator() {
     return Data.GetSubAccounts(account);
  }
}


public class SubAccount {
   public Account account {get; set;}    //this is public so that my Data class can access the account, to get the account's user's ID.

   public SubAccount(Account account) {
      this.account = account;  
   }

   public Report GenerateReport() {
       Data.GetReport(this);
   }

}


public static class Data {

  public static List<Account> GetSubAccounts(Account account) {

      using (var dc = new databaseDataContext()) {
          List<SubAccount> query = (from a in dc.Accounts
                                where a.UserID == account.User.ID  //this is getting the account's user's ID
                                select new SubAccount(account) {
                                    ID = a.ID,
                                    Name = a.Name,
                                }).ToList();
      }

  }

  public static List<Account> GetAccounts(User user) {

     using (var dc = new databaseDataContext()) {
         List<Account> query = (from a in dc.Accounts
                               where a.UserID == User.ID  //this is getting the user's ID
                               select new Account(user) {
                                   ID = a.ID,
                                   Name = a.Name,
                               }).ToList();
     }
  }

  public static Report GetReport(SubAccount subAccount) {

     Report report = new Report();
     //database access code here
     //need to get the user id of the subaccount's account for data querying.
     //i've got the subaccount, but how should i get the user id.
     //i would imagine something like this:
     int accountID = subAccount.Account.User.ID;
     //but this would require the subaccount's Account property to be public.
     //i do not want this to be accessible from my other project (UI).
     //reading up on internal seems to do the trick, but within my code it still feels
     //public. I could restrict the property to read, and only private set.

     return report;
  }

  public static List<User> GetUsers() {

     using (var dc = new databaseDataContext()) {
         var query = (from u in dc.Users
                     select new User {
                       ID = u.ID,
                       FirstName = u.FirstName,
                       LastName = u.LastName,
                       PhoneNo = u.PhoneNo
                     }).ToList();

         return query;
     }
  }

}

Answer 1

这个答案最终包含了很多流行语标题。希望我能解释每一项以及为什么它适用于此。我认为我下面介绍的每个概念都值得考虑 - 它们并不总是适用，但我发现它们都是我个人在考虑系统结构时认为有价值的东西。

单一职责

首先考虑每个对象的职责 - 它的工作是什么？一般来说，一旦您决定为每个类别指定一个作业，您就会找到更好的设计。目前，您的许多类做得太多了，保留了真正应该作为服务存在的逻辑。

上面的第一个示例是您的 User 类：

public class User { 

   public string ID {get;set;} 
   public string FirstName {get; set;} 
   public string LastName {get; set;} 
   public string PhoneNo {get; set;} 

  public AccountCollection accounts {get; set;} 

  public User { 
     accounts = new AccountCollection(this); 
  } 

  public static List<Users> GetUsers() { 
     return Data.GetUsers(); 
  } 

} 

为什么它提供了从数据源检索用户的方法？该功能应该移出到用户服务中。

另一个关键示例是 SubAccount 上的GenerateReport 方法 - 不要将报告生成逻辑与 SubAccount 对象紧密联系在一起。将其拆分将为您提供更大的灵活性，并减少子帐户更改破坏报告逻辑的情况。

延迟加载

再次查看您的 User 类 - 为什么它在实例化时加载所有用户帐户？每次与用户一起工作时是否总是会使用这些对象？

通常最好引入延迟加载 - 仅在需要时检索帐户。当然，有时您需要预先加载（如果您知道您很快就会需要该对象，因此希望减少数据库访问），但您应该能够针对这些异常进行设计。

依赖注入

这种类型是从延迟加载点和单一责任点开始的。您有很多对数据类等内容的硬编码引用。这使得您的设计更加严格 - 重构数据访问以引入延迟加载，或者更改用户记录的检索方式变得更加困难，因为许多类都直接访问数据访问逻辑。

摘要对象

向 Cade Roux 致敬 - 我从未听说过“摘要对象”这个术语，通常将其称为轻量级 DTO。

正如 Cade 所说，如果您所做的只是显示绑定到唯一 id 的用户名组合框，则没有理由检索包含功能齐全的用户对象的丰富列表。

引入一个轻量级的用户对象，它只存储非常基本的用户信息。

这又是引入服务/存储库抽象和某种依赖注入的另一个原因。当您将数据检索与实际对象封装在一起并且没有与数据访问实现紧密绑定时，更改从数据存储中检索的对象类型会变得更加容易。

得墨忒耳定律

你的物体对彼此的内部结构了解太多。允许从用户深入到帐户，然后再深入到子帐户会混淆每个对象的职责。您可以从用户对象设置子帐户信息，但实际上您不应该这样做。

我总是在这个原则上挣扎，因为钻探层次结构似乎很方便。问题是它会阻止你仔细思考每个对象的封装和角色。

也许不要向用户公开您的 Account 对象 - 而是尝试引入公开 Account 对象的相关成员的属性和方法。查看 GetAccount 方法而不是 Account 属性，以便您强制自己使用帐户对象而不是将其视为 User 的属性。

Answer 2

延迟加载 - 除非被访问，否则不要在 Users 中创建 AccountCollection 对象。或者，您可以让它与用户同时检索帐户集合，从而避免 1 + 9000 次数据库访问。

拥有更具选择性的集合检索方法（即您要对 9000 个用户做什么？如果您需要他们的所有信息，那也不算浪费）。

拥有较小的“摘要”对象，用于长列表（如下拉列表和查找） - 这些对象是简单的只读业务对象 - 通常仅包含少量信息，可用于检索完全成熟的对象。

如果要进行分页，用户列表是加载一次并存储在 Web 服务器中，然后从缓存的副本中分页，还是每次从数据库加载集合并由控件完成分页？

Answer 3

好的，现在就对代码进行快速评论。

public class SubAccount {
   public Account account {get; set;}    //this is public so that my Data class can access the account, to get the account's user's ID.

    public SubAccount(Account account) {
        this.account = account;  
    }
    [snip]
}

如果将 Account 属性传递到 ctor 上，然后将其分配给支持字段，则您甚至不需要在该属性上设置 setter。

通过将属性传递给 ctor 来设置属性可能是一个非常好的实践，但是如果您的数据对象要被序列化，即如果它被检索或发送到 Web 服务，那么它就会失败 - 在这种情况下，您将Account 属性至少需要一个内部 setter。

编辑：您仍然可以在构造函数上使用此 DI 类型行为，但问题是当对象从序列化形式重新水化时（即，当它已传递给/来自网络服务）。因此，如果您要使用 Web 服务，您还需要有一个无参数构造函数，以及 Account 属性上的公共或内部 setter（如果您要使用内部 setter，那么您还需要指定 AssemblyInfo.cs 文件中的 InternalsVisibleToAttribute。