Как обрабатывать создание / редактирование объектов в master-detail

Question

Мне интересно, какие стратегии люди используют для управления созданием и редактированием сущности в настройке мастер-детали. (Наше приложение является настольным приложением с поддержкой Интернета.)

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

У меня есть несколько вопросов и замечаний по поводу вышеуказанного рабочего процесса:

• кто должен заниматься созданием копии объекта? (мастер или деталь)
• мы используем copyFrom () для предотвращения необходимости замены сущностей в коллекции, что может привести к разрыву ссылок. Есть лучший способ сделать это? (реализация copyFrom () может быть хитрой)
• новые сущности получают идентификатор -1 (который серверный уровень / гибернация использует для различения между вставкой или обновлением). Это может вызвать проблемы при поиске (кэшировании) сущностей по id перед их сохранением. Должны ли мы вместо этого использовать временный уникальный идентификатор для каждого нового объекта?

Может кто-нибудь поделиться советами, хитростями или опытом? Спасибо!

Редактировать : Я знаю, что нет абсолютно неправильного или правильного ответа на этот вопрос, поэтому я просто ищу людей, которые поделятся своими мыслями и плюсами / минусами о том, как они справляются с ситуациями мастер / детали.

Answer 1

Существует несколько способов изменить этот подход. Имейте в виду, что никакое решение не может быть «неправильным» само по себе. Все зависит от деталей вашей ситуации. Вот один из способов снять кожу с кошки.

кто должен заниматься созданием копии объекта? (мастер или деталь)

Я вижу мастер как представление списка в памяти подмножества постоянных сущностей. Я бы позволил мастеру обрабатывать любые изменения в своем списке. Сам список может быть пользовательской коллекцией. Используйте событие ItemChanged, чтобы инициировать уведомление мастера о том, что элемент обновлен и его необходимо сохранить. Запустите событие NewItem, чтобы уведомить мастера о вставке.

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

Вместо использования copyFrom () я бы передал существующую ссылку во всплывающее окно сведений. Если вы используете перечисляемую коллекцию для хранения главного списка, вы можете передать объект, возвращенный из списка [index], в окно сведений. Сама ссылка будет изменена, поэтому нет необходимости использовать какой-либо метод Replace в списке. Когда нажата OK, запустить событие ItemChanged. Вы даже можете передать индекс, чтобы он знал, какой объект нужно обновить.

новые сущности получают идентификатор -1 (который серверный уровень / гибернация использует для разграничения между вставкой или обновлением). Это может вызвать проблемы при поиске (кэшировании) сущностей по id перед их сохранением. Должны ли мы вместо этого использовать временный уникальный идентификатор для каждого нового объекта?

Изменения не сохраняются сразу? Используйте Hibernate Session с шаблоном Unit of Work , чтобы определить, что вставляется и что обновляется. Есть и другие примеры работы. Возможно, вам придется проверить некоторые сообщения в блоге сообщества .NET, если на стороне Java не так много. В любом случае это одно и то же животное.

Надеюсь, это поможет!

Answer 2

Я только что реализовал такую ​​модель. Но не использую NH, я использую свой собственный код для сохранения объектов в Oracle Db.

Я использовал концепцию основных деталей в той же веб-форме.

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

В режиме подробного добавления, я просто заполняю пустую сущность, чей идентификатор был сгенерирован в отрицательных числах, статическим полем. И на кнопке Сохранить детали я сохраняю эту сущность в списке деталей основной записи в сеансе Asp.NET. 1007 *

В режиме «Редактирование деталей», «Просмотр» я заполнил панель «Детали» выбранной деталью с помощью вызовов ajax с использованием Jquery и добавил это наказание чуть ниже строки, по которой щелкнули.

При сохранении кнопки я сохранил мастер-сессию (содержащую список деталей) в базе данных.

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

также, если хотите, вы можете использовать Jquery Modal для вызова этой панели вместо добавления под строкой.

Надеюсь, это поможет :) Спасибо,

Answer 3

Библиотека CSLA может помочь в этой ситуации.

Однако, если вы хотите самостоятельно реализовать:

У вас есть главный объект, главный объект содержит список дочерних объектов.

Форма сведений может редактировать дочерний объект напрямую. Поскольку все являются ссылочными типами, главный объект автоматически обновляется.

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

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

Вы также можете обработать это интерфейс INotifyPropertyChanged.

Что касается некоторых других ваших вопросов:

Вы хотите отделить свою логику. Сущность может управлять хранением своих собственных свойств и правил целостности для себя, но логика взаимодействия различных объектов друг с другом должна быть отдельной. Посмотрите на такие шаблоны, как MVC или MVP.

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

Для идентификаторов использование GUID в качестве идентификатора может спасти вас от множества проблем, потому что тогда вам не нужно обращаться к базе данных, чтобы определить правильный идентификатор. Вы можете оставить флаг на объекте, если он новый или нет (и поэтому должен быть вставлен или обновлен).

Опять же, CSLA обрабатывает все это для вас, но имеет довольно много накладных расходов.

относительно отмены при отмене: CSLA реализовал отмену n-уровня, но если вы пытаетесь сделать это вручную, я бы либо использовал вашу функцию CopyFrom, либо обновлял данные объекта со слоя персистентности при отмене (повторный выбор ).