Надоело писать подобное для каждого свойства




Надоело копипастить. Решил придумать, как бы покороче. Самое простое, что пришло в голову:




Ну и строковые параметры имён свойств приходят через выражения (Expression), так что хардкодинга, вроде, нет, и рефакторинг спасён.

Проблема в том, что хотелось бы избежать возвращаемых и принимаемых типов object, чтобы не приходилось заниматься приведением типов. Вроде, как-то это можно через шаблоны (generics) сделать. Как? Подскажите, пожалуйста.



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

Вобщем, хотелось бы мнения послушать.

VIT2708user7320,

Может тебе стоит в таких случаях ОБОБЩЕННЫЕ МЕТОДЫ ИСПОЛЬЗОВАТЬ

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


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

АбсолютУ меня чисто такой вопрос, не по теме.

У вас Cancel в диалоге редактирования EMail есть? И если да, то как реализовано возвращение предыдущих значений?
Если я вас правильно понимаю, то вы говорите о том случае, когда модель представления (МП) содержит в себе объект модели (М) в качестве поля, и когда значения полей этой М изменяются при редактировании контролов представления (П), представляющих собой поля М (через привязанные свойства МП). Т. е. получается, что когда, например, контрол адреса е-мейла теряет фокус, то поле е-мейла М автоматически получает новое значение. При этом старое значение теряется и его уже не вернуть.

Ну, для этого, как я думаю (сам я такого не делал) либо организуете буферный объект, который будет хранить в себе текущую копию модели с изменениями, и по Submit копировать заменять текущий объект М буферным, либо по Cancel удалять буферный и оставлять текущую М без изменений.

Либо ещё вариант, когда у вас есть репозиторий, то буфером в этом случае является сама М. После Submit вы вызываете из репозитория Update и обновляете значение в репозитории текущей М. По Cancel - просто ничего не делаете с репозиторием, в результате у вас сохранились старые значения.

Самое же простое, изменять поля М не после потери фокуса каждым контролом, а после нажатия Submit изменять уже всю М целиком по МП с уже сделанными изменениями.

Как-то так. Вроде, элементарно?

user7320Самое же простое, изменять поля М не после потери фокуса каждым контролом, а после нажатия Submit изменять уже всю М целиком по МП с уже сделанными изменениями.
Только с мгновенной валидацией придётся распрощаться - только общая сводка после Submit.

авторВот, что меня слегка смутило:
Это из джошесмитовского примера скопировано:




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

Нажав Cancel, мы (по сценарию примера Джоша) закрываем П сущности, одновременно уничтожается её МП и М, лежащая в основе. Точнее, не уничтожается, а становится "ненужной" (сборщик мусора и всё такое). Тогда да, данные остаются нетронутыми в репозитории.

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