А как такая хрень вообще происходит?
насчёт Unit of work ты меня убедилОн есть
Мы даже что-то подобное у себя используем.
Только кроме функций из методичек insert, remove и get у нас например есть GetListWithIncludes<TEntity>(Expression<Func<TEntity, bool> condition, Expression<Func<TEntity, object> include)
или UpdateOneProperty<TEntity>(int id, Action<TEntity> setter)
Я боюсь, если кто-то решит мигрировать на другой ОРМ, нам всем станет очень больно.
Щас натравлю на вас DBA, которые скажут, что эта хрень должна быть в хранимках. А любая орм хранимку-то дёрнет без проблем.
Ну и для пачки методов с изъёпистыми запросами целый паттерн городить не надо. Просто поместите их в ваш класс изъёпистых запросов и всё.
Но за 20 лет столько всего изменится, что никакие крутые теории не спасут.
Особенно, когда всё начиналось с гаража х лет назад.Я сейчас работаю в проекте, который начался боьше 20 лет тому назад. И у нас до сих пор есть куски кода, которые уже 20 лет работают. И уже хрен знает сколько лет в проекте используется оракл, черти сколько лет тому назад был спроектирован слой взаимодействия с БД и за последние 2 года там было пара расширений и пара багфиксов.
Возможно когда-нибудь придется все это выбросить и перейти на что-то другое, но сейчас этот код работает, проблем не доставляет и нет ни одной причины его выбрасывать.
А UI за 20 лет тоже без изменений? А если с изменениями, как старое дерьмо с новым UI стыкуется? Через пачку абстракций?
И да, это имеет смысл. Лучше с самого начала добавить "тупой" сервис, который "тупо вызывает репозиторий", чем через два года пытаться разодрать монструозный репозиторий на собственно репозиторий и сервис. И пытаться понять что делать с сервисами, которые вызывались напрямую из этого репозитория и как убирать тучу обратных связей.
Для управления всеми этими сервисами нужен отдельный сервис. Или лучше система сервисов. Иерархическая. Там должен быть мастер-сервис, подсервисы, и рядовые сервисы. Там же нужно продумать систему специализированных сервисов-хостов для всех этих сервисов. Репозиторий сервисов тоже был бы неплох. Также может пригодиться фабрика репозиториев сервисов по созданию сервисов.
Если вы не какой-нибудь SAP или Твиттер, то и свой фреймворк, и продукт на его основе, и команды поддержки для всех клиентов вы навряд ли потянете. Впрочем, уже по второму кругу пошло обсуждение.В нулевых я работал на фирме, которая делала сайты. И у нее - сюрприз! - был свой самописный CMS. Который мы развивали. А сайты делались на этом CMS-е. Клиентов было что-то в районе 40-50 фирм. Никаким сапом там не пахло. Нас в бекэнде было 3 человека. И тянули, и развивали и для клиентов новые свистелки реализовывали. Так что помолчи уже, за умного сойдёшь.
В нулевые у каждого школьника был свой фреймворк. И с теми не столь обширными веб-технологиями это ещё как-то было поддерживаемо небольшими командами. Сейчас либо вы очень большой, либо вас раздавят.
Значит, у вас есть команды, специализирующиеся по ормам. Либо челы, знающие несколько ормов. Либо вы берёте только те проекты, по технологиям которых имеете спецов.
Либо можно просто сделать абстракцию, которая будет независима от ОРМа и тогда можно брать все проекты :)
Мы как бы всё ещё говорим о конторе, клепающей на заказ сайты и прочие проекты, а не поддерживающей своё костыльное болото десятилетиями?
Именно так. И как показывает практика, работать на "своем костыльном болоте" получается гораздо эффективнее (как минимум с точки зрения бизнеса).
А UI за 20 лет тоже без изменений? А если с изменениями, как старое дерьмо с новым UI стыкуется? Через пачку абстракций?
UI с изменениями. Пару лет назад начали мигрировать UI с WinForms на WPF, сейчас вот закончили этот процесс. UI отделена от бизнес логики. Так было и в WinForms.
А что, есть такие, кто не отделяет UI от бизнес логики? 
Щас натравлю на вас DBA, которые скажут, что эта хрень должна быть в хранимках. А любая орм хранимку-то дёрнет без проблем.
ты молодёжь попробуй заставь писать pl/sql
Да и это пришлось бы на каждый пук писать свою хранимку.
А с инклудами вообще можешь забыть.
Ну и для пачки методов с изъёпистыми запросами целый паттерн городить не надо. Просто поместите их в ваш класс изъёпистых запросов и всё.
Нет уж лучше так, чем 100500 методов типа
GetCustomerByIdWithAdress
GetCustomerByNumberWithOrders
GetOrdersByDateWithCustomers
И т.д.
Мы делаем софт для машин. Ну и соответственно нужно UI для управления этими машинами.а UI тоже на машинах работает?
В чём проблема? У меня на старой работе тоже делали софт для машин. Подключаешься к автомобильному компу и шуруешь там. Мы газовали, крутя крутилку в интерфейсе нашей программы.
Либо можно просто сделать абстракцию, которая будет независима от ОРМа и тогда можно брать все проекты :)
Зависит от качества и уровня проработки этой вашей абстракции. Чтобы использовать все возможности ормов (не то что одной, а хотя бы нескольких), да ещё обновлять свою абстракцию с обновлениями ормов, абстракция должна быть сложнее любого этого орма по архитектуре. Ну и соответствующая команда на эту бандуру.
А если тяп-ляп, лишь бы простые команды поддерживала, то можно, конечно, и на коленке слепить кусок костыля.