我应该使用带参数或函数的方法吗？

我有一个哲学编程问题。假设我有一个名为Employees的类。员工拥有从dataTable中设置的业务成员。为了填补这一点，我使用了一个方法，该方法需要雇员类的一个实例，通过dataTable循环，并设置传递给它的实例的成员。例如：我应该使用带参数或函数的方法吗？

public void GetEmployees(objEmployee) 
{ 
    //the function I am calling returns a dataTable of all the employees in the db. 
    dim dt as DataTable = dbEmployees.GetEmployees(); 

    foreach(DataRow drow in dt.rows) 
    { 
     objEmployee.Name = drow["Name"].ToString(); 
     objEmployee.ID = drow["ID"].ToString(); 
    } 
}

然后我会叫这样的代码在我的UI逻辑：

public void GetEmployees() 
{ 
    Employees employee = new Employees(); 

    employee.GetEmployees(employee); 
}

我的问题是，是否可以接受我的类的实例传递到一个方法和更改属性就像我现在这样，还是会更加面向对象的，通过这样的功能做到这一点：

public Employees GetEmployees() 
    { 
    Employees objEmployee = new Employees(); 

    //the function I am calling returns a dataTable of all the employees in the db. 
    dim dt as DataTable = dbEmployees.GetEmployees(); 

    foreach(DataRow drow in dt.rows) 
    { 
     objEmployee.Name = drow["Name"].ToString(); 
     objEmployee.ID = drow["ID"].ToString(); 
    } 

    return objEmployee 


}

然后，我会这样称呼它：

private void GetEmployees() 
{ 

Employees employee; 

employee = employee.GetEmployees(); 
}

在方法上使用函数有什么优势吗？谢谢！

来源

2009-02-06 Austin

这两件事都是方法（也称为函数）。不同的是，第一个“通过引用返回”，而第二个“返回引用”。

在C＃中通过引用返回没有优势，因为在更简单，自然的情况下，只返回引用，不会执行复制（与C++不同）。

因此，返回引用总是首选，因为它是最简单的，并且它允许在调用站点（例如嵌套表达式：manager.Fire（GetEmployee（））方面具有很好的语法灵活性，而不需要单独声明）。

来源

2009-02-06 19:30:53

对我来说听起来像你应该让GetEmployees（）成为Employee的静态方法。您不应该实例化员工以获取他们的列表。

此外，您的第一个示例只是将您的objEmployee设置为您数据中最后出现的任何内容。当它遍历所有员工时，它会在到达最后一个时停止循环，这是您将返回的数据。

此外，“员工”类是指一名员工还是多名员工？相应地命名它。如果“员工”代表一个“员工”，那么也许您应该将其重命名为“员工”，并从GetEmployees方法返回一个列表，如上所述，该方法应该是静态的，因此您可以简单地调用诸如“员工”之类的东西。装getEmployees（）”。这就是说，我永远不会太喜欢你为业务对象提供数据访问功能的架构。它倾向于将数据访问层和业务对象层耦合得太紧。

您可能需要考虑创建一个Data Access接口，该接口接受用于搜索员工的参数并返回实际的Employee对象作为结果。一旦你这样做了，你会想创建一个这个数据访问层的实现，然后你将使用它来生成实际的实例。这样做的好处是可以快速更改数据访问层的实现，而无需更改业务对象。然后，您可以将业务对象编程为接口，然后您可以使用动态装配加载或其他方法来动态确定数据访问的实现。

来源

2009-02-06 19:27:32

啊，你是对的。抱歉;这不是实际的代码，只是我搞砸了一个例子:)你会建议什么来解耦数据访问层和业务层？ – Austin 2009-02-09 18:07:39

这完全取决于您的应用程序的体系结构。我通常会建议将DAL放入它自己的程序集中，与域对象分开，并从DAL引用域对象，而不是反过来。业务层应该是相对独立的。 – 2009-02-09 18:16:51

但是，如果你这样做，你还是有同样的问题吗？如果您不得不从数据层引用域对象，它是如何独立的？ – Austin 2009-02-09 19:12:07

public void GetEmployees(objEmployee) 
{ 
    //the function I am calling returns a dataTable of all the employees in the db. 
    dim dt as DataTable = dbEmployees.GetEmployees(); 

    foreach(DataRow drow in dt.rows) 
    { 
     objEmployee.Name = drow["Name"].ToString(); 
     objEmployee.ID = drow["ID"].ToString(); 
    } 
}

在第一种方法中，如果没有员工，你会怎么做？您创建了Employe对象并传递方法来填充它，然后您要检查是否有员工。但是当你想要检查的时候，将不会有空值，因为你发送了创建的对象。我认为第二个更好，更容易理解。

Employees employee = new Employees(); 

employee.GetEmployees(employee); 

if(employee==null)//but employee is not null?? 
    DoSomething();

来源

2009-02-06 19:45:57 mcaaltuntas

我应该使用带参数或函数的方法吗？

回答

相关问题