Все остальные правы, что это создает два отдельных класса. Чтобы не создавать два отдельных класса и отделить ваши данные от логики с помощью частичных классов, в вашем проекте могут быть следующие два файла:
- Employee.cs
- Employee.bl.cs
Тогда ваш код Employee.cs будет выглядеть так:
namespace YourNamespace
{
partial class Employee
{
public string EmpID { get; set; }
public string EmpName { get; set; }
}
}
И Employee.bl.cs будет выглядеть так:
namespace YourNamespace
{
partial class Employee
{
public static List<Employee> GetListOfEmployees()
{
//DATA ACCESS
var emps = GetEmployeesFromDb(); // fetch from db
return emps;
}
}
}
Хотя я бы подумал, что наличие класса Repository для извлечения данных было бы более уместным, чем наличие GetListOfEmployees внутри Employee.
Обновление:
Когда я говорю о хранилище, я имею в виду шаблон проектирования хранилища . Репозиторий - это интерфейс для извлечения и хранения объектов (например, из реляционной базы данных). Если вы используете ORM, такой как LINQ to SQL или ADO.NET Entity Framework, они обычно автоматически генерируют классы, которые выполняют эту роль. Если, однако, если вы пишете свой собственный код доступа к базе данных, вы можете создать свой собственный класс репозитория, например:
public class Repository
{
public Repository(string connectionString)
{
// ...
}
public IEnumerable<Employee> GetEmployees()
{
return GetEmployeesFromDb();
}
public Employee GetEmployeeById(Guid id)
{
// ...
}
public void StoreEmployee(Employee employee)
{
// ...
}
// etc.
}
Преимущество этого заключается в том, что вам не нужно размещать код базы данных в вашем классе Employee или любом другом постоянном классе. Весь доступ к базе данных осуществляется через один интерфейс. Вы также можете создать interface и иметь несколько реализаций хранилища; таким образом, вы можете иметь способ хранить Employee экземпляров в файле, например, без необходимости изменять класс Employee.