C#(OOP)嵌套的Business Objects

3 c# asp.net oop

我今天收到了一位同事发来的电子邮件.我的问题是准确的.嵌套Business Objects是不好的做法?任何人都可以发光吗?

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

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

我们将'supervisorId'字符串变量添加到Employee类,并添加适当的Getters和Setters.

另一方面,我们希望避免在员工对象中嵌套另一个对象.如:public class Employee {private string firstName; private string lastName; 私有字符串empId; 私人员工主管;

    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; }
 }
  }
Run Code Online (Sandbox Code Playgroud)

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

有些情况需要嵌套对象:示例:(类别::问题)每个类别可以有一个分配给它的问题数组列表.

Jos*_*eph 8

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

嵌套业务对象是不是很糟糕?

没有.

长期的答案是,听起来你的团队正在遭受过早的优化.您需要设计业务对象以镜像业务域.您的业​​务领域中的所有行为都应在您的业务层中进行说明.一旦达到目标,就可以进行性能测试.实际测量系统的哪些部分太慢,然后优化这些部分.在你甚至没有机会完成它之前,不要陷入预先优化你的业务逻辑的境地.

设计并实施,然后进行性能测试,然后在发现不可接受的缓慢时进行优化.