Какова наилучшая практика для обработки сложных объектов как членов класса?

Question

Хорошо, для базового примера говорят, что у меня есть приложение с расходами, и каждый расход в моей базе данных SQL имеет идентификатор, идентификатор сотрудника и сумму. Должен ли я сделать это:

public class Expense 
{ 
    public int Id { get; set; } 
    public Employee Employee { get; set; } 
    public decimal Amount { get; set; } 
} 

Или так:

public class Expense 
{ 
    public int Id { get; set; } 
    public int EmployeeId { get; set; } 
    public decimal Amount { get; set; } 
} 

Вы видите, что я обычно сделать первый, и когда я принести расход из базы данных я бы установить поле Employee, вызвав конструктор как : Employee = new Employee(int id) это сделало бы еще одну поездку в БД, чтобы заполнить элементы в объекте Employee. Это удобно, потому что теперь я могу получить доступ к членам/функциям сотрудников через счет. I.E. если я привязан как объект ObjectDataSource, я мог бы отобразить что-то вроде Eval("Employee.Name") и показать что-то более дружелюбное, а затем просто число, поскольку оно хранится в БД.

Однако текущий проект, над которым я работаю, может занять 10 тысяч тысяч строк, а количество запросов БД будет ракета-небо, если я получаю данные о первом счете, а затем детали сотрудника для каждого объекта. (и на самом деле мой текущий проект имеет таблицу с 6-7 внешними ключами).

Есть ли способ иметь мой торт и есть его тоже?

Возможно, имея класс интерфейса только с полями Id, а не с полными полями объекта? но я чувствую, что я никогда не понимал интерфейсов, поэтому я не уверен, что это изменит ситуацию.

Спасибо всем, кто зачитал это далеко, даже если у вас нет ответа для меня.

Answer 1

Это зависит: Если вы используете многофункциональный ORM (NHibernate), который может обрабатывать такие вещи, как отношения, то 1-й код будет более удобным; или если это ваши объекты View Model, вы можете делегировать эту задачу движку DI (например, Ninject).

Если дизайн вашего приложения требует большего контроля над тем, как объекты приходят и уходят, или если вы используете Expense сильно (не Employee), вы должны использовать 2-й дизайн (конечно, у NHibernate есть сложный набор инструментов для кеширования, который можно использовать для реализуйте это).

Answer 2

Мне кажется, что ваш второй пример не помешает вам получить как расходы, так и работника в наборе данных. С другой стороны, я бы предположил, что у вас может быть много расходов для одного empoyee, поэтому, если вы получите 1000 расходов, связанных с 100 сотрудниками, тогда у вас будет 1000 сотрудников, которые будут перемещаться вокруг, причем 900 из них будут мертвым весом. То, как вы представляете их в классах, не обязательно изменяет то, как вы представляете их в базе данных.