Так много умных слов..
А суть-то проста как трусы пожарника:

Вместо
Onчто-то-тоClick() {Код реализации какого-то алгоритма}

надо писать

Onчто-то-тоClick() { Вызов функции, которая реализует какой-то алгоритм}

что напрямую соответствует не каким-то там надуманным паттернам типа MVVM, а SOLID - совершенно научной концепции проектирования решений.

Помницца, еще в васике лет дцать назад били меня за все эти Button100500 и пихание кода непосредственно в обработчик.

Что касается модели, точнее ORM, то ее никто не мешает использовать в ЛЮБЫХ приложениях, в т.ч. при написании ОС и драйверов.
Лишь бы вес коробки не превышал веса его содержимого :)

По поводу "бизнес-логики".

У меня в последнее время возникают мысли, что многие девелоперы работают с ораклом, причем к самому ораклу (БД) их не пускают на пушечный выстрел. Знаю, что это за ситуация на примере саппорта АС "Парус". Дерьмо то еще - все выкрутасы приходится мастерить на "клиенте", порождая монстроидальные SQL-конструкции.
Но ведь SQL-серверы обладают мощнейшим инструментом реализации этой самой бизнес-логики (триггеры, констрэйнты, индексы, хранимки, UDF, вьюхи и куча еще всего). Причем при грамотной настройке алгоритмов все это летает на миллионных таблицах.

Но нет !
Мы не знаем SQL, SQL-сервера, нам не дают, требует заказчик, хочет любимая (нужное подчеркнуть) - и мы тянем в ORM только таблички, а там ( в ORM) строим небоскребы, висячие сады и каскадные водопады логики. И героически пытаемся рулить транзакциями, чтобы все это ложилось в концепцию целостности БД.

Возможно, я ошибаюсь, но именно такое складывается впечатление :)

Еще замечание. Пускать девелопера в проекты с БД (а таких сейчас немного больше, чем все) без знания хотя бы основ этих самых СУБД - все равно, что сажать блондинку с картой-маршрутом в самолет. Грохнется, еще не взлетев :)
Мне сейчас возразят - а нафих например linq. Ну во-первых, этим псевдоинструментом никак не заменишь полноценный скрипт на SQL, во-вторых, чтобы понять все его нюансы, нужно немногим меньше времени, чем изучить "родной" SQL. В-третьих, как быть с планами запросов ? Т.е. с оптимизацией выполнения этих самых запросов ? В хранимке у меня полный набор от создания индексов до использования особенностей конкретного SQL-сервера. А что есть в LINQ кроме заявления его авторов о его крутости ?
Не проще ли всю бизнес-логику вынести на этот самый SQL-сервер ? Что гарантированно удобнее как при масштабировании, так и при "перезде" на сервер иного типа - просто переписал БЛ с MS SQL на MySQL (к примеру), оставив неизменными названия и типы сущностей модели. И все !

Хотелось бы услышать мнение уважаемых постояльцев форума по этому поводу :)

Да что Вы говорите.
А вынос алгоритмики (кода) из обработчика (UI) в основной блок кода (Model), о чем и было написано выше - это не есть "перенос", о котором так трындят все эти псевдотеоретики ? Или будем спорить чтоб было раньше - яйцо или курица ?

Вот есть конкретный пример.

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

Как решить ?

Немного упрощаем и получаем два основных пути.

1. Создаем ОДНУ ORM и туда пихаем всю БД всей СУБД. На выходе имеем:
Плюс: все, что надо, есть. Берем только то, что надо для решения конкретной задачи.
Минус: получаем монстроидальный код ORM, куда не заглядываем дабы не посетил Панкратий (инфаркт миокарда)
Минус 2: имеющейся в ORM имплиментации и классов не хватает, чтобы оптимально решить задачу. Выход - пишем собственные маленькие ORM-ки, городим модельки, сеем репозиторийки и прочее. Лезть в "большую" ORM нам, сермяжным и посконно-лапотным, ессно, не дозволяют. И, кстати, правильно делают !
Минус 3: отладка. "проверенный" метод ORM жутко тормозит или возвращает эксепшн на моих параметрах. Решается долгими и частыми перебранками с орм-щиками. Чаще всего не в нашу пользу. В итоге переделываем логику своего проекта. "А это бандитизм" (с)

2. Для решения каждой задачи лезем на сервер и там строим БЛ. Получаем кучу "своих" хранимок, UDF и т.д. Т.е. строим свою ORM для задачи.
Плюс: в проекте нет ничего лишнего. Каждую строчку кода знаем как белье собственной жены. Все оптимизации, модернизации и прочие "ции" - в наших руках.
Минус: т.к. мы не одни, а задач много, БЛ на сервере разбухает как чиряк на носу - стремительно и независимо. На мой взгляд (непросвещенный) - ну и Христофор Бонифатьич с ним ! Чиряком в смысле. На то он и сервер, он железный. Кроме того, существуют схемы, роли и т.д., позволяющие гибко управлять объектами этой БЛ, отдавая нужные ее части в нужные руки.

Что имеем в сухом остатке:
- если судить с т.з. конечного юзера, то он явно выигрывает при втором пути: приложение на его десктопе (точпаде) не тормозит.
- С т.зр. инвестора - тоже второй предпочтительнее - не надо платить космические зарплаты орм-щикам ибо без них "все станет" - достаточно иметь одного-двух эскюэлщиков (которых, кстати, все равно нужно иметь) .
- С т.зр. разраба тоже предпочтительнее. Почему ? Ведь время на проектирование конкретной задачи резко уменьшается, не так ли ?
Не так ! Ибо разобраться в чудовищно раздутой ORM может оказаться куда труднее, чем спроектировать свою собственную, "под задачу". Я уже не упоминаю затраты на отладку, тестирование и опытную эксплуатацию - говорил об этом выше.

Итак, господа, мой вывод - "корпоративный" ORM-фтопку ! Больше децентрализации, господа, больше власти и свободы на места ! Пусть каждый увидит как собственное величие, так и дурь.

Аминь

Еще про ORM.

Каковы истинные причины ее возникновения ? Вернее, даже не ее самой, а мысли о ней ?
Дела в том, что в те годы, когда такая мысль могла возникнуть, дела с скл-серверами обстояли совсэм не так пушисто-розово как сейчас.
Промышленных серверов было "обмаль", стоили они как небольшое предприятие и их обслуживание обходилось инвесторам в кругленькие суммы. Доступ к "телу" был либо закрыт, либо чреват всякими "негараздами". Вот и думали чуваки, как бы сделать чтоб и клубничку съесть и на сервер не залезть. Вот они и придумали выход.
Но очень скоро "ураклисты" (я буду их так называть, всяк поймет кто имеется в виду) смекнули, что денюжки ("Ух, какие крупные деньжищи") уплывают мимо их алчных ротов. И они взялись за сооружение собственных ORM. И теперь: нужна вам АС управления все- равно-чем ? Пожалте к нам - мы вам дадим (вернее продадим) ORM в красивой коробочке. Есно, с Хранилищем. С каким ? А нафих вам знать - все будет замеч т ательно бегать, даже летать ! Так появился отряд привилегированных айтишников, которые сами себе и выдумали название - бэкенд. Но не "попа с концом", как подумала бы учительница английского в начальных классах, а совсем-совсем иное. Т.е. условные "ураклисты" переобулись на лету в бэкэндистов. Гордо носящих это имя, что и понятно, их средние жалования в разы превосходят подаяния, получаемые "фронтами".

Что мы имеем в сухом остатке ? А имеем деление разрабов на две основные касты - каста "белых" и каста .."афроамериканцев" :)
И ладно бы.. Но ведь лезут же изо всех форумов эти "спесилисты", освоившие драг-энд-дроп всяких оэрэмовских эсдэкашек, и с выпяченной хилой грудью громогласно пинают тех, кто пытается что-то мастерить на SQL-серверах.

Несправедливо это, господа :)