C # бизнес-объекты и коллекции - PullRequest
6 голосов
/ 20 января 2010

Мне трудно обернуть голову вокруг бизнес-объектов или, более конкретно, коллекций бизнес-объектов.

Вот краткий пример того, что я пытаюсь сделать.

Если у меня есть объект инцидента, в этом объекте может участвовать несколько человек, и каждый из этих объектов Person может иметь несколько заметок. Заметки не могут существовать без объекта Person, а объекты Person не могут существовать без объекта Incident.

Если у меня есть Публичный список notes = new List (), такие методы, как ADD и REMOVE, становятся доступными для Person в рамках Incident. Я предполагаю, что если бы я должен был вызывать эти методы в коллекции Notes, он просто удалит его из списка, но не выполнит никакого кода, чтобы фактически добавить / обновить / удалить сотрудника из источника данных. Это приводит меня к мысли, что я должен использовать не Список, а что-то еще?

Это также подводит меня к другому вопросу. Где должна находиться действительная база данных CRUD . Должен ли объект Note иметь свой собственный CRUD или объект Person должен отвечать за него, поскольку он не может существовать без него?

Я немного растерялся, по какому пути идти, и я бы хотел, чтобы эта часть была правильной, потому что это будет шаблон для остальной части программы.

Ответы [ 3 ]

1 голос
/ 20 января 2010

Я делаю это так: каждый объект, имеющий дочерние объекты, содержит их список, а каждый объект с родителем содержит свойство с его типом. Добавление выполняется путем заполнения объекта (или иерархии объектов) и отправки в DAL для сохранения, если это необходимо. Все операции CRUD выполняются в DAL, который не зависит от типов объектов, но использует такие типы, чтобы определить, к каким таблицам, столбцам и т. Д. Получить доступ. Удаление - это единственное, что решается по-разному, путем установки свойства Deleted объекта, которое вызывает DAL для его удаления.

Теперь о бизнес-логике - она ​​ не находится непосредственно в самих объектах (DAO), а скорее в классах, которые получают или собирают такие DAO, когда это необходимо, выполняют свою работу и отправляют DAO обратно в DAL для обновления.

1 голос
/ 20 января 2010

Была предоставлена ​​некоторая полезная информация, но вы упомянули одну вещь, которая может сбить вас с толку:

"Если у меня есть заметки из публичного списка = новые List () затем такие методы, как ADD, УДАЛИТЬ стать доступным для Персона внутри инцидента. "

Все зависит от того, как вы разрабатываете свои классы. Вы должны подумать о том, как эти данные связаны друг с другом. Это поможет вам представить дизайн вашего класса.

Звучит так:

  • В одном инциденте может участвовать много людей
  • Один человек может создавать множество заметок
  • Записка является самым низким уровнем и существует в связи с создаваемым инцидентом и ответственным лицом (лицами), работающими над этим инцидентом.

Инцидент 1 - много человек

Персона 1 - много заметок

Вы можете установить такой тип отношений несколькими способами. Одним из способов может быть фактическое разделение задействованных объектов, а затем создание объединенных объектов.

Например

public class Incident {
//insert incident fields here
//do not add person logic / notes logic
//probably contains only properties
}

public class Person {
//insert person fields
//private members with public properties
//do not embed any other logic
}

public class Comment {
 //insert comment private fields
 //add public properties
 //follow the law of demeter
}

Эти классы не предоставляют друг другу подробности, они просто хранилища для хранения этой информации. Затем вы связываете эти классы друг с другом, например

public class IncidentPersonnel {
List<Person> p;
//add methods to add a person to an incident
//add methods to remove a person from an incident
....
}

Тогда у вас может быть другой класс, обрабатывающий комментарии персоналом

public class PersonnelNotes {
List<Note> n;
//other methods...
}

Вы можете пойти дальше с этим, но это может усложнить ситуацию, но я просто даю вам другое представление о том, как справиться с этим.

Попробуйте следовать закону деметры для функций

Инкапсулируйте все ваши объекты, кроме того, ваш сосед может разговаривать с вами, но не с чем-то еще ... Это поможет вам слабо связать ваши классы и сделает процесс мышления для вас немного проще.

Наконец, вы упомянули, как должны работать операции CRUD. Все это восходит к вашему DAL (уровень доступа к данным). Вместо того, чтобы возвращать строки данных из таблицы, вы могли бы затем возвратить ссылочный объект со всеми его атрибутами. Добавляйте и удаляйте работу одинаково (передавая или удаляя объект). Вы можете использовать ORM или написать свой собственный DAL. Все зависит от того, насколько вы хотите вовлечь себя:).

1 голос
/ 20 января 2010

У вас есть несколько разных вопросов в одном, я постараюсь ответить на большинство.

В отношении проблем, связанных с использованием List<T> - у платформы есть ReadOnlyCollection<T>, что полезно именно в вашей ситуации. Это коллекция, которая не позволяет добавлять или удалять созданный файл.

В отношении ответственности за работу CRUD - которая должна принадлежать вашему уровню данных, а не любому из ваших объектов (см. SRP - Принцип единой ответственности).

...