ну да, монстр работает и живет. эта штука самая живучая оказалась. если бы я сдуру запретил мешать бизнес-код в презентерах вьюшек с собственно презентационной логикой, было бы вообще шикарно.
Трудно сделать юнит-тест? Сделай легкий апи, который позволит написать автотест.
Сложно с ОЛАП-ом? Сделай БД для олтп, сделай бд для datawarehouse через ssis, сделай куб через datawarehouse, а не через изначальную БД — будет гораздо логичнее.
Ну и т.п. Критерий — проще. Макконел писал про нагрузку на интеллект. Чем проще нагрузка, тем круче жить. Чем более понятнее и тупее аспект приложения, тем выше шанс, что результирующий бизнес-функционал получится полнее и более восприимчивым к изменениям. Чем проще базовые методы и инварианты, тем круче и проще строить логику на уровне выше. И т.п.
Архитектор должен все это понимать. У вас похоже чувак (чуваки) грезят всемирной славой.
вот — очень круто сказал:) 20-30 разработчиков и тестеров, но в РФ никто в ИТ не понимает необходимость такого подхода. Минимизация такова, что пусть напишут говно, которое тестируется уже в проме на клиентах, чем будут держать штат из кучи разработчиков.
Такое делают только те люди, которые сами проработали в Штатах\Лондоне и все на своей шкуре почувствовали. Яркий пример — Parallels — ребята жгут напалмом, софт один из лучших.
Не знаю, что надо сделать, чтобы у нас были такие команды разработчиков? Разве что самому бизнес организовывать.
Последний предложенный вопрос\метод — это создание всемирного управлятора. Собственно, было опробовано у нас, спасибо, хватит:)
По-моему, чем толще система, тем разнесеннее нужно делать уровни. Слои, черные ящики и т.п. — конкретно что и как должно быть не скажу, не знаю какая у вас там должна быть кухня. Я у себя сделал слой данных, слой бизнес-логики, которая по факту оборачивает методы слоя данных и т.п.:) получается кошерно, жалко нет времени все добротно доделать.
С аттрибутами знаю точно, должны спасти DTO. Если все интерфейсы между слоями определить через dto то доработки по добавлению\удалению полей будут идти в несколько раз легче. Но что-то мне говорит, что никто тебе\вам этого сделать не даст:)
Нет, ну мы были достаточно разумны, чтобы не лезть в исходники или апдейтиться при каждом выходе новой версии.
Все таки все это от лешего, все эти финтифлюшки и гемор там не из-за докрутки функционала, а из-за того, что не существует общего поведения контролов. Датасорс девэкспрессовского комбобокса не биндится, например. MRUEdit не умеет искать по вхождению. CheckedComboboxEdit не позволяет биндиться на отмечаемые коллекции. В treelist нет галочек, опять же как класса — нужно подпихивать свои иконки. И т.п.
Короче все эти мелочи жутко досаджают — приходится писать тонну своих элементов. В конце концов пришло понимание — что да, это таки красиво и юзабельно, но блин, сколько же лишнего!
Таблица есть? пиши круд в хранимках.
Добавилось поле? Пиши поле в хранимке.
Трудно проводить регресс? Сделай юнит-тест.
Трудно сделать юнит-тест? Сделай легкий апи, который позволит написать автотест.
Сложно с ОЛАП-ом? Сделай БД для олтп, сделай бд для datawarehouse через ssis, сделай куб через datawarehouse, а не через изначальную БД — будет гораздо логичнее.
Ну и т.п. Критерий — проще. Макконел писал про нагрузку на интеллект. Чем проще нагрузка, тем круче жить. Чем более понятнее и тупее аспект приложения, тем выше шанс, что результирующий бизнес-функционал получится полнее и более восприимчивым к изменениям. Чем проще базовые методы и инварианты, тем круче и проще строить логику на уровне выше. И т.п.
Архитектор должен все это понимать. У вас похоже чувак (чуваки) грезят всемирной славой.
Нет:) не в.нете.
Такое делают только те люди, которые сами проработали в Штатах\Лондоне и все на своей шкуре почувствовали. Яркий пример — Parallels — ребята жгут напалмом, софт один из лучших.
Не знаю, что надо сделать, чтобы у нас были такие команды разработчиков? Разве что самому бизнес организовывать.
По-моему, чем толще система, тем разнесеннее нужно делать уровни. Слои, черные ящики и т.п. — конкретно что и как должно быть не скажу, не знаю какая у вас там должна быть кухня. Я у себя сделал слой данных, слой бизнес-логики, которая по факту оборачивает методы слоя данных и т.п.:) получается кошерно, жалко нет времени все добротно доделать.
С аттрибутами знаю точно, должны спасти DTO. Если все интерфейсы между слоями определить через dto то доработки по добавлению\удалению полей будут идти в несколько раз легче. Но что-то мне говорит, что никто тебе\вам этого сделать не даст:)
Юниттесты все же круче тем, что они отделены от кода, тогда как контракты должны быть с ним тесно связаны.
Но тема интерсная, спасибо.
Все таки все это от лешего, все эти финтифлюшки и гемор там не из-за докрутки функционала, а из-за того, что не существует общего поведения контролов. Датасорс девэкспрессовского комбобокса не биндится, например. MRUEdit не умеет искать по вхождению. CheckedComboboxEdit не позволяет биндиться на отмечаемые коллекции. В treelist нет галочек, опять же как класса — нужно подпихивать свои иконки. И т.п.
Короче все эти мелочи жутко досаджают — приходится писать тонну своих элементов. В конце концов пришло понимание — что да, это таки красиво и юзабельно, но блин, сколько же лишнего!
Фишка контрактов в изначальной интегрируемости?