C# 我应该使用带参数的方法还是函数？

我有一个哲学编程问题。假设我有一个名为Employees的类。员工拥有从数据表中设置的业务成员。为了解决这个问题，我使用了一个方法，该方法获取employee类的一个实例，在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();
}

然后我会这样称呼它：

 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();
}

---

使用函数比使用方法有什么优势吗？谢谢

听起来您应该将GetEmployees（）作为Employee的静态方法。您不必实例化员工来获得他们的列表

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

另外，“Employees”类是指一个员工还是指多个员工？据此命名。如果“Employees”代表一个“Employees”，那么也许您应该将其重命名为“Employees”，并从GetEmployees方法返回一个列表，正如我前面所述，该方法应该是静态的，因此您可以简单地调用类似“employeen.GetEmployees（）”的内容

话虽如此，我从不太喜欢为业务对象提供数据访问功能的体系结构。它倾向于将数据访问层和业务对象层耦合得太紧

您可能想考虑创建一个数据访问接口，它接受用于搜索雇员的参数，并将实际的雇员对象作为结果返回。一旦您这样做了，您就会希望创建这个数据访问层的实现，然后使用它来生成实际的实例。这样做的好处是，您可以快速更改数据访问层的实现，而无需更改业务对象。然后，您可以在接口之外对业务对象进行编程，并且可以使用动态程序集加载或其他方法来动态确定数据访问的实现

两者都是方法（也称为函数）。区别在于第一个“通过引用返回”，而第二个“返回引用”

在C#中通过引用返回没有任何优势，因为在更简单、自然的情况下，只返回引用，不进行复制（与C++不同）

因此，返回引用始终是首选，因为它是最简单的，并且它允许调用站点具有极大的语法灵活性（例如嵌套表达式：manager.Fire（GetEmployee（）），而不需要单独的语句）

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

Employees employee = new Employees();

 employee.GetEmployees(employee);

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

---

啊，你说得对。很抱歉这不是实际的代码，只是一个我搞砸了的示例：）那么对于数据访问层和业务层的解耦，您有什么建议？这完全取决于应用程序的体系结构。我通常会建议将DAL放在它自己的程序集中，与域对象分开，并从DAL引用域对象，而不是相反。业务层应该是相对独立的。但是，如果这样做的话，您不是仍然有同样的问题吗？如果必须从数据层引用域对象，那么它是如何独立的呢？我建议创建一个单独的DAL来引用BOs，或者在两者之间创建一个第三层，即“业务逻辑”（BL）层，以弥合DAL和BOs之间的差距。虽然DAL可能会返回一个数据表或其他东西，但BL会将其转换为您的BOs。然而，无论采用哪种方式，业务对象都将独立于DAL，但没有法律规定DAL必须独立于业务对象。您是对的。在第一种情况下，通过使用一系列方法，它更加灵活。