C# (OOP) 嵌套业务对象

Question

我今天收到一位同事发来的以下电子邮件。我的问题是这样准确。嵌套业务对象是不好的做法？任何人都可以对此大放异彩吗？

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

以上面的第二个员工对象为例......如果我们还需要知道员工的主管 ID..(这就是所有工具填充和使用的)我们希望确保 Employee 类包含适当的信息，同时考虑工具中的内存和进程。

我们会将“supervisorId”字符串变量添加到 Employee 类，并添加适当的 Getters 和 Setters。

另一方面，我们希望避免在 employee 对象中嵌套另一个对象。例如: 公共(public)课员工{ 私有(private)字符串名字； 私有(private)字符串姓氏； 私有(private)字符串 empId； 私有(private)员工主管；

    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) 每个类别都可以分配一个问题数组列表。

Answer 1

对您的一般问题的简短回答

Is it bad to nest business objects?

不是。

长话短说，听起来您的团队正在遭受过早优化的困扰。您需要设计您的业务对象以反射(reflect)您的业务领域。你的业务领域中的所有行为都应该在你的业务层中被举例说明。实现该目标后，您就可以进行性能测试了。实际测量系统的哪些部分太慢，然后优化这些部分。在您甚至有机会对其进行布局之前，不要陷入预先优化您的业务逻辑的困境。

设计和实现，然后进行性能测试，并在发现 Not Acceptable 缓慢时然后进行优化。