МСУViPRosэто я называю контрактом.
Это не контракт, это банальная обработка исключения. Я тоже так умею
значит не въехал
у тебя настройка маппинг - разовая процедура, после маппинга никто не отслеживает изменение в серверной стороне (ну, конечно, если ты там один, тоо перенастроишь маппинг, сгенерируешь тонну "классов", изменишь свои "пратиал классы" (костыли одним словом) и вышлешь "новую версию" бедным юзверам, а они будут трахаться с БД и т.д.)
а у ВИПРОС перманентный маппинг с возможной потерей функциональности прикладного кода, но с четким предупреждением о петере функциональности прикладного кода и причине потери, а сама ВИПРОС непотопляема. :)

ПарамонShSergeпропущено...

А вы его, как все нормальные люди, тестируйте сначала под манажемент студией и смотрите при этом план запроса (желательно).
Тот факт, что компилятор не выдал ошибки, абсолютно не означает, что запрос правильный. :)

Пока все нормальные люди тестируют о смотрят планы каждого мелкого запроса я предпочитаю заниматся чем то полезным )
Да, и незабудте проверять и тестировать все запросы после каждого изменения логики, я подозреваю времни у вас не меренно :)
значит твое полезное не зависит от реакции системы твоей
бывают такие гениальные проги, выхлоп которой можно ждать и год, если этот выхлоп = лечение рака или мылен баксов

LelouchViPRosпропущено...

значит не въехал
у тебя настройка маппинг - разовая процедура, после маппинга никто не отслеживает изменение в серверной стороне (ну, конечно, если ты там один, тоо перенастроишь маппинг, сгенерируешь тонну "классов", изменишь свои "пратиал классы" (костыли одним словом) и вышлешь "новую версию" бедным юзверам, а они будут трахаться с БД и т.д.)
а у ВИПРОС перманентный маппинг с возможной потерей функциональности прикладного кода, но с четким предупреждением о петере функциональности прикладного кода и причине потери, а сама ВИПРОС непотопляема. :)

Да, есть некоторые субстанции, которые не тонут... Сори, не удержался.
Кстати так и не понял разницы в плане удаления объекта БД. Что мегасупавипрос при попытке обращения (насколько я понял) выдаст Ихсепшн (или как ты там извратнулся над словом Exception), что EF выдаст его же при выполнении запроса.
ну тут на форуме токо для того и собираются что бы друг дружка нетонущим срванивать
так что не переживай, ты не первый
ЕФ выдасть ихзепшн и твоя прога скорее всего умрет
а ВИПРОС сам же обработает (спрячеть или сделаеть пункт меню или кнопочку недоступной, не запустит прогу и т.д.)
а если БД изменится средствами ВИПРОС то она просто не дасть ее изменить, если это приведеь к потере функциональности в зависимости от прав)

LelouchНикто не запрещает перехватывать исключения EF.
Кнопочка это очень просто. А если выполняемая операция является частью последовательности операций, например выполняемых в 1 транзакции? Я предпочту исключение и откат транзакции, чем отсутствие вызова метода и неправильные результаты работы.
P.S. Слабо представляю зачем заказчик сам полезет в базу, да еще через левый механизм.
1.Ты их не перехватываешь. Уверен.
2. Зачем откатывать то, что изначально не пройдет.
3. Ты слабо представялешь что такое левая система. Для нормальной системы левой является DBA и что то типа SSMS.

Lelouch1. Мне даже в страшном сне не надо представлять изменение БД заказчиком. (А если он все же это изменит без санкции меня как разработчика, и программа ляжет, то он же мне и платить будет за восстановление...)
2. Что изначально не пройдет? написано подряд вызов 5и методов, 3й не работает. Остальные 4 же выполняться?
3. То что MS SMS не является необходимой для работы системы я согласен. Но не ты, ни "випрос" не могут запретить пользователю влезть в БД с ее помощью. Отсюда ценность прав на изменение БД в твоем "випрос" = 0.

P.S. Я не могу понять как Хорошим решением может быть возможность пользователя как угодно влезть в БД, изменить ее структуру, а потом еще надеяться на правильную работу бизнес-логики. То что программа не будет вылетать с исключениями - не является признаком правильной работы.
1. Как бы ты не старался описать предметную область (п.о.)) исчерпывающим образом (если она не стандартизировано) у тебя это не получится в силу объективных причин. Потому лучше дать возможность модельщику доописать п.о. А вот это "доописать" должно быть стандартизировано, токо тогда заказчик может привязать стандартное отраслевое ПО к своей п.о.
2. Вызов 5 методов не должно реализоваться хардкодингом. Пользователь может написать или переписать некторые из них. Значит должен быть применен способ межметодного :) общения, т.е. настравиавмые рабочие потоки (благо в НЕТ это встоена). А вот вход этого настраиваемого рабочего потока должен быть четко специфирован, что бы можно было бы эти спецификации можно было сверить со спецификациями поставщика инфы и при несовпадение не запускать рабочий потокю Нефиг вызываь часть потока, если изначально ясно что поток завершится ошибкой из за несоблюдения интерфеса поставщиком. так как точка входа в рабочий поток известен (обычно это визуальный интерфесный элемент), то можно его блокировать.
2. Т ыможешь изменить БД как цгодно, просто ВИПРОС при запуска потока проверит согласованность контекста требований и предложений. Но, рекомендуемый способ изменения - через менеджер метаданных ВИПРОС, тогда коллизий воще не возгикнет.

Lelouch1. Пока-что это получалось.
2. Почему это не должен быть? Мне нужно выполнить 5 методов в строгой последовательности (и это отнюдь не единичный случай). Мне вот даже интересно, как ты блокируешь элемент управления?


Ты из этого кода поймешь, что блокировать надо?) (Даже если использовать RoutedCommand - за разрешение выполнения команды отвечает CanExecute, а не Execute).

3. Мне не нужно чтобы его менял заказчик. У заказчика часто даже нет ИТ отдела, только пара админов. Кто у него будет ПО дописывать? (Это кстати справедливо и для весьма крупных предприятий, а-ля водоканалы (наш основной профиль). Их ИТ отделы состоят из 10ка человек, которые и так умирают на поддержке универсальной межотраслевой 1С. Второе такое счастье им особо не надо, поэтому заказывают системы "под ключ".)

P.S. И как ты будешь обновлять ПО заказчика, если он может переписать твою систему как ему вздумается?
P.P.S. Судя по сайту ВИПРОС я бы его стандартным межотраслевым ПО не назвал.
1. Рад за тебя.
2. Лучше вызов этих 5 методов оформить как рабочий поток, конфигурацию которой можно поменять в любое время не меняя прогу.
3. Вот ты описал какой то вентиль для водопроводной трубы. Там диаметр, напор и т.д. не знаю что. твоя система работает в орловской губернии. А в Брянской губернии есть вентили с 2 регулируемыми положениями. Что для брянщину надо переделать прогу? или лучше дать возможность ввести новые параметры для венитля и переделать метод (написать другой)? я думаю второй вариант лучше.
4. ПО и БД обновляется автоматом, с учетом изменений внесенных пользователем в ПО и в БД.
5. ВИПРОС платформа. На неу написаны несколько отраслевых решений (ВИП.Бюджетирование, ВИП.APS, ВИП.MES и т.д.)

Lelouch,

1. популярность тут не при чем, если випрос сделает для тех, кто ее спонсировал, то что им надо, то это уже будет 100 миллионов экономии для страны
2. ты зациклился на рефлексии, у випрос свои метаданные, и она знает все о своих формах, кнопках, методах, событиях и т.д. и автоматом их генерирует из метаданных
3. ты просто НЕ МОГ ЗНАТЬ что у вентиля будет N положений (никто пока не сконструировал :) и никакой фаулер тебе в этом не поможет

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

Lelouch,

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

МСУViPRos2. ты зациклился на рефлексии
Отгадай с одного раза, - на чём ты зациклился?
ViPRosв общем, все мы пишем мертвые проги
Нет уж. Ты пишешь мертвые проги, а мы создаем хорошие решения ;)
уйди, противный