Ассоциация: использовать идентификаторы или ссылки на объекты?

Question

У приложения, которое я помогаю поддерживать, нет реальных бизнес-объектов, о которых можно говорить, несмотря на то, что это значительный, якобы n-уровневый проект. То, что наша команда называет «бизнес-объектами», на самом деле представляет собой не что иное, как автоматически сгенерированные оболочки вокруг строк нашей базы данных, и вся действующая бизнес-логика смешивается с кодом веб-интерфейса. Что касается новых функциональных возможностей, мне бы очень хотелось, чтобы наша команда начала работать с / кодировать объекты, которые действительно представляют данные и поведение бизнес-сущностей, и максимально не допускают бизнес-логику в пользовательский интерфейс. Однако существует некоторый конфликт о том, как должны моделироваться отношения.

Чтобы значительно упростить домен для целей здесь, скажем, у вас есть Персоны и Задачи. Каждой задаче назначен человек.

public class Person
{
    public int ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; } 
}

Как должно моделироваться задание?

public class Task
{
    public int ID { get; set; }
    public string Title { get; set; }
    public int AssignedPersonID { get; set; } 
}

OR

public class Task
{
    public int ID { get; set; }
    public string Title { get; set; }
    public Person AssignedPerson { get; set; } 
}

Те, кто тратит больше времени на кодирование веб-интерфейса, хотят получить более раннюю версию, в которой Person ссылается по своему идентификатору. Они утверждают, что когда, скажем, другому человеку назначен другой человек, лучше просто изменить task.AssignedPersonID (новый идентификатор легко доступен из их выпадающего списка в пользовательском интерфейсе) и записать в базу данных. Для меня это не отличается от подхода, который мы используем сейчас; это все еще отражает строку базы данных больше, чем фактическая бизнес-модель. Они утверждают, что это больше кода и медленнее, чтобы взять этот PersonID, создать экземпляр соответствующего экземпляра Person, а затем установить task.AssignedPerson, когда конечный результат - то, что столбец AssignedPersonID в таблице Task - обновляется точно так же .

С объектно-ориентированной точки зрения, какой здесь предпочтительный подход?

Answer 1

С объектно-ориентированной точки зрения предпочтительным подходом является использование объектов, а не идентификаторов.

Однако, как вы указали, ваше приложение не объектно-ориентировано.«Объекты» не являются коллекцией геттеров / сеттеров.У них есть поведение («бизнес-логика»), которое, я уверен, нет у ваших автоматически генерируемых классов.То, что вы хотите сделать, звучит отлично, но я подозреваю, что будет много работы, чтобы убедить других.

Answer 2

Я бы предпочел иметь фактическую ссылку на объект, а не только идентификатор.

Если у вас есть только удостоверение личности, и вы часто будете использовать его для поиска человека, чтобы что-то с ним делать, вы в плохой форме, потому что такие частые поиски потребуют времени. Если, с другой стороны, у вас есть объект Person, и вместо него вам нужен идентификатор, это так же просто, как вызвать Person.ID.

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

Так что, хотя это зависит от специфики, я думаю, что большинство программистов ОО предпочли бы иметь фактическую ссылку на объект.

Кстати, в названии используются слова «Родитель» и «Дочерний», которые (вы, вероятно, уже знаете) имеют специфическое значение в контексте наследования в объектно-ориентированном программировании. Для меня это не похоже на отношения между родителями и детьми, а скорее на отношения «это использует». Ваш вопрос совершенно верен, но заголовок / заголовок может быть немного вводящим в заблуждение, и вы можете получить лучшие ответы с несколько иной терминологией.

Answer 3

Я бы определенно сказал, что второй вариант, т. Е. Относится к реальному человеку. Предположим, что класс задачи должен отправить сообщение на назначенный человек. Почему он должен знать, как получить человека по ее идентификатору? Я не понимаю, насколько уместен ваш вопрос: «Если на задание назначен другой человек ...»: кто его назначает? Тот, кто назначает его, должен лучше знать назначенное лицо (или знать, как получить доступ к этому человеку по его идентификатору), это не должно быть делом рабочего класса.

Это не проблема производительности, производительность, вероятно, будет такой же, речь идет о хорошем дизайне и наличии классов с одной ответственностью.

Answer 4

Вызывает ли Task когда-либо методы назначенного ему лица? Можете ли вы предвидеть обстоятельства в будущем, когда в Task может захотеть вызвать методы назначенного им лица? Является ли человек особенно дорогостоящим для создания экземпляра по какой-либо причине?

Нет причин не ссылаться на фактический экземпляр Person, если только это не является проблемой производительности.