Имеется класс бизнес-логики Технология. Он имеет такие поля как шапка технологии (примечание, разработчик, дата создания итп) и коллекцию переходов технологии. Переход технологии это тоже полноправный класс со своими полями и методами.

Для отображения Технологии на экране имеется пользовательский контрол ТехнологияКонтрол.

ТехнологияКонтрол расположена на форме, которая имеет такие кнопки интерфейса как "Изменить шапку", Добавить/Изменить/Удалить/Редактировать переходы.

Для взаимодействия всего этого я хочу применить стандартный подход Model-View. Т.е. форма приложения запросив от пользователя данные о изменении в шапке или о новом переходе отправляет их классу Технология. Технология поднимает ссответствующие события, которые ловяться классом ТехнологияКонтрол, который в свою очередь изменят свой вид.

Проблема в том, что для операций Удалить/Редактировать переход нужна ссылка на текущий переход технологии, которым обладает только ТехнологияКонтрол. Получается как-то через задницу - ТехнологияКонтрол должен обладать методами Удалить/Редактировать текущий переход, внутри которых он должен править объект Технология, а затем ловить события Технологии об ее изменении.

Нормально-ли это, или лучше пойти более прямолинейным путем и например внутри методов "Удалить/Редактировать текущий переход" просто править объект Технология и тут-же приводить себя в соответствующий вид ?

softwarer
Вот это с точки зрения модели MVC уже не слишком правильно. Подумайте вот о чем: допустим, Вы все запрограммировали, а завтра я хочу вывести в статусбар название текущего перехода. Статусбар в данном случае - это другой view, который цепляется к той же модели. Следовательно, информация о текущем выделении должна быть частью модели - Вы же не хотите, чтобы статусбар цеплялся к ТехнологияКонтрол?

хм, т.е. если я вас правильно понял, бизнес-класс должен знать, какой переход выделил пользователь ? Вообще, в данном конкретном случае это идея, но вот если представить себе гипотетический случай (который для какого-нибудь другого класса может оказаться вполне даже реальным) когда имеется два и более представления объекта на экране (например сокращенное представление технологии (без части информации - например без текста перехода) и развернутое, и пользователь может переключаться между ними) - то это перестанет работать.
Вообще вы натолкнули меня на мысль, что ТехнологияКонтрол просто может иметь public свойство "ВыделенныйПереходТехнологии". Тогда можно редактировать его, а ТехнологияКонтрол будет ловить событие об изменении. В случае если вы захотите прицепить статусбар, можно ТехнологияКонтрол наградить еще и событием СменилсяВыделенныйПереход (где параметром передать ссылку на переход - и если ее где-нибудь сохранить, то можно даже обойтись и без public свойства).
Вы правы, действительно, статусбар тогда прицепиться не к модели, а к ТехнологияКонтрол, но честно говоря я не понял, почему я этого не должен хотеть. Имхо, выделение текущего перехода весьма слабо относиться к предметной области Технология и не вписывается в его интерфейс.

softwarer
Совершенно не обязательно и более того, глупо. "Удалить текущий" - довольно дурная операция, которая если и может существовать, то только как дополнение к основной "удалить указанный".

согласен

softwarer
В нормальной логике второй вариант не годится.

Спасибо. Значит работаем на событиях.

Если позволите, возник еще один вопрос. На самом деле переходы бывают разные, есть два совершенно различных класса переходов, даже без общего предка. Выделен на экране может быть только какой-то один из них. Как следует определять, какой тип перехода выбран ?
Можно наверное просто поднимать события ВыделенПереходТипа№1 и ВыделенПереходТипа№2, где параметрами передать ссылку на переход и затем сохранить эту ссылку в переменную соответствующего типа. Но тогда потом придется перебором определять, какая переменная содержит реальное значение, а какая null, что имхо нехорошо

softwarer
В модели MVC все данные хранятся в моделях - согласны?

согласен

softwarer
"Выбранный элемент" либо "элементы" - это тоже данные

не согласен. Вернее, не согласен, что это данные предметной области. Вот если создать отдельно стоящую модель, которая отвечает только за управление выбором - то да. Но тут не понятно, почему нельзя эти функции отдать ТехнологияКонтрол. Наверно более правильно будет сказать, что если-бы действительно было несколько разных представлений, фильтров, статусбаров и прочих вещей, зависящих от выбора текущего перехода, то можно было-бы создать дополнительную прослойку управляющую выбором активных элементов, но у меня всего одно представление, где информация какой элемент выбран по сути нужен этому-же представлению :) А как известно, нужно старательно избегать введения дополнительных сущностей, если нет веских причин для обратного.

softwarer
Нет, не перестанет. С какой стати? Второе представление просто не использует ненужную ему информацию, но от наличия этой информации оно не сломается :)

Вообще-то я имел ввиду ситуацию, когда пользователь может выделить разные переходы на этих представлениях. И если вы храните указатель на выбранный элемент прямо в бизнес-классе, то сделать этого неудасться. Я конечно понимаю, что обычно люди выделяют все-таки что-то одно, и затем это что-то, как вы указали, может использоваться в других представлениях, потому и назвал эту ситуацию гипотетической :)
Кстати здесь есть другой интересный момент - если вдруг я завтра захочу вместо одной выделенной записи сделать мультиселект, то при хранении такой информации в бизнес-объекте мне придется его править, что явно выглядит очень странно.

softwarer
Потому что это получается бардак. Если Вы хотите работать в MVC - попробуйте все же принять ее суть. Вы хотите наградить представление функцией модели. Допустим, для статусбара - именно статусбара - это будет вроде как локальная приемлимая особенность. А представьте, что завтра Вы захотите, чтобы на основании выбора пользователя выполнялась хранимка в БД, которая например блокирует выбранную запись - что Вы будете делать тогда? Тоже положите этот код в "визуальную" часть?

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

softwarer
Ну а естественная мысль - внести в данные еще и "активный список". Либо в виде перечислимого значения, либо, если совсем эстетствовать - как ссылку на "активную модель".

А можно поподробнее ? Честно говоря не понял, что именно имеется ввиду под "активной моделью". Т.е. есть коллекция элементов, состоящая из элементов разных типов. Выделили один элемент. Как "снаружи" определить, какой элемент и какого типа был выделен ? Помечать какой тип является активным ?

softwarer
Если этот элемент действительно нужен только этому представлению и заведомо не потребуется никому другому, то согласен - вполне можно закопать "выбранный элемент" внутри и не публиковать его.

Однако, почему я говорю о публикации - потому что MVC рассчитан на работу в подчеркнуто модульных условиях; Вы вообще говоря не вправе рассчитывать на то, кто и как завтра будет использовать Ваши классы. Синхронизация представлений, в том числе "выбранного элемента" - требование довольно естественное. Тут мы уже уходим в философский вопрос "что есть лишняя сущность, а что - разумная предусмотрительность". Решать это в общем-то Вам.

ну полностью-то закопать выбранный элемент внутри представления все-же нельзя, тема этого топика и была как раз о том, как-бы оповещать окружающих о том, какой элемент стал активным. Вообще я пока склонился к мысли, что лучше всего просто внутри ТехнологияКонтрол поднимать событие о смене текущего элемента, где параметром передать ссылку на бизнес-класс выделенного перехода.
Ну а то, что решение о том, применять-ли дополнительный класс для этого является философией - так это же хорошо, вся инженерная наука строиться на подобных "филосовских" рассуждениях. Например с филосовской точки зрения мне не кажется, что имеет смысл заводить класс, единственный толк от которого будет только в том, что он сможет мне сообщить какой переход выделен, если я могу спросить это напрямую у представления. Хотя возможно в дальнейшем, с учетом того, что есть 2 разных типа переходов (и даже немного сложнее) возможно найдутся аргументы в его пользу.

softwarer
Ээ... не понял. Как он может выделить разные переходы, если на втором представлении "сокращенная информация" и переходов, как я понял, нет?

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

softwarer
Однако, давайте в общем случае: если есть два представления, завязанные на одну модель данных, они скорее всего должны использовать также и общую модель выделения. Скажем, в качестве примера: слева у Вас CheckListBox, в котором мультиселектом выделяются переходы, а справа - StaticText, текст в котором формируется как список выделенных переходов через запятую.

я как раз говорил о том, что два разных представления вполне могут иметь разные модели выделения. Скажем, редактирует технологи переход, открыв для этого специальное окно для редактирования. Соответственно, на ТехнологияКонтрол этот элемент и является выделенным (иначе он бы просто не смог начать его редактирование). Но вдруг в процессе он осознает, что ему необходимо посмотреть какую-то информацию из другого перехода. Тогда он открывает второе представление в отдельном окне, где может выделить другой переход для просмотра или чего-нибудь еще. Пример конечно высосан из пальца, но согласитесь ничего невероятного в этом нету.

softwarer
Не его. Вы дополните класс SelectionModel, включенный в класс данных. В самой модели данных при этом не изменится ни строчки.

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

Это все относиться к случаю, если имеется дополнительный класс-прослойка SelectionModel, ответственный за поведение при выделении. Мои комментарии относились к случаю, когда такая информация лежит прямо в бизнес-классе.

softwarer
Я так понял, что у Вас есть два списка переходов разных типов. Для работы с ними можно опубликовать из модели две "подмодели" - типа "левый список и правый список" - и кроме того, сделать ссылку на "активную модель". Тогда, если элементы полиморфны, операции с ними можно будет реализовать без единого if-а.

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

softwarer
P.S. Как я упомянул, это уже бесполезное эстетство, не думайте об этом слишком много :)

ну почему-же бесполезное, да и думать - это минимум не вредно, и даже наоборот :)

softwarer
Ээ... брать выделенный элемент, смотреть его класс

Получаются if'ы. А если-бы типов было не два, а двадцать ? Неужели по-другому никак нельзя ? Получается, что поймав событие от ТехнологияКонтрол (или класса-прокладки следящего за выделениями), я начинаю if'ами определять его класс и затем складывать в переменную соответствующего типа ? Правда еще можно сразу сложить его в переменную типа object, а затем при попытке удалить/отредактировать определить его тип. Правда здесь нет принципиальной разницы :)