C#（面向对象编程）嵌套业务对象

Question

我今天收到了一封来自同事的电子邮件。我的问题是这是否准确。嵌套业务对象是不好的做法吗？有人可以对此发表意见吗？

嵌套对象 当在C#中创建任何变量时，它会占用Web服务器上的一部分内存。由于我们将在同一台服务器上运行许多工具，因此更加重要的是要确保我们不会创建不需要使用的对象。

以上面第二个员工对象为例... 如果我们还需要知道员工的主管ID...(并且这是该工具正在填充和使用的全部内容)，我们将希望确保Employee类包含适当的信息，并考虑到工具中的内存和进程。

我们将添加'supervisorId'字符串变量到Employee类中，并添加适当的Getter和Setter。

另一方面，我们将希望避免在employee对象中嵌套另一个对象。例如：     public class Employee {         private string firstName;         private string lastName;         private string empId;      private Employee supervisor;

    public string FirstName {
        get { return firstName; }
        set { firstName = value; }
    }

    public string LastName {
        get { return lastName; }
        set { lastName = value; }
    }

    public string EmpId {
        get { return empId; }
        set { empId = value; }
    }

 public Employee Supervisor{
     get { return supervisor; }
     set { supervisor = value; }
 }
  }

在这种情况下，我们可能不总是使用Employee对象的'Supervisor'实例中的值，而是在内存中创建变量。这可能会对性能产生潜在的灾难性影响。

有一些情况下需要嵌套对象： 例如：（Category :: Question）每个类别可以分配一个问题数组列表。

- x2ws

Answer 1

您的一般问题的简短答案是不会。

长答案是，听起来您的团队正在遭受过早优化的困扰。您需要设计业务对象以反映您的业务领域。您业务领域中的所有行为都应在业务层中体现。一旦达到了这个目标，您就可以进行性能测试。实际测量系统中哪些部分太慢，然后优化这些部分。不要在连布局都没有完成之前就被业务逻辑的预优化所拖累。

先设计和实现，然后进行性能测试，最后在发现无法接受的缓慢时再进行优化。

- Joseph

Answer 2

我相信以下的业务对象（数据传输对象）引发了这封电子邮件：

    /// <summary>
    /// Manufacturer Data Transfer Object
    /// </summary>
    public class MfgBO {
        public int Id { get; set; }
        public string Name { get; set; }
        public bool Active { get; set; }
    }
  }

public class TypeBO {
        public int Id { get; set; }
        public string Name { get; set; }
        public bool Active { get; set; }
    }


 public class ModelBO {
        #region Private Variables

        private int mmtId = -1;
        private int id = -1;
        private string name = String.Empty;
        private bool active = false;
        private MfgBO mfg = new MfgBO();
        private TypeBO type = new TypeBO();

        #endregion
        // Getter and setters below

看这个ModelBO持有MfgBO和TypeBO，因为一个模型没有这些信息是不完整的。他建议的是在ModelBO中，我们应该有一个变量int MakeID、string MakeName、int DeviceTypeId、string DeviceTypeName等，基本上重新输入已经存在于MfgBO和TypeBO对象中的字段。

根据我的有限OOP知识，使用MfgBO和TypeBO更有意义。哪种方式对我个人的知识更好？在MakeBO中使用MfgBO和TypeBO会实际使用更多的内存并“潜在地使服务器崩溃”吗？

- x2ws

---

你现在的方式（使用Mfg和Type作为独立的对象而不仅仅是Model的附加属性）确实会消耗更多的内存（因为每个对象都有一些小的内存开销），但这并不重要。如果你的服务器因此崩溃，我认为这意味着你一开始就过度加载了服务器。 - MusiGenesis

保持当前设计的一个优点是，将这些对象分开使您能够轻松地进行重构，以适应每个型号有多种类型或每个型号有多个制造商的情况。 - MusiGenesis

我认为Joseph的回答是正确的：你的同事只是过早地进行了优化，接近于完全的愚蠢。 - MusiGenesis

Answer 3

只有在明确访问时才能创建对象。

public BusinessObject Item
{
    get
    {
        if (_Item == null)
            _Item = new BusinessObject();

        return _Item; 
    }
}
private BusinessObject _Item;  

- ChaosPandion

Answer 4

我的观点是，只有在您经常调用嵌套对象的方法时才应该进行嵌套。

如果您只是获取嵌套对象的一些属性，则不应将其嵌套，并应直接存储属性。

- Vinko Vrsalovic

Answer 5

从您的代码示例中可以看出，您正在通过属性设置器外部设置主管员工对象，因此我认为这种设计是可以的。如果每次创建“外部”员工对象时都自动实例化主管对象（例如通过访问数据库），则可能会存在潜在问题。

- MusiGenesis