А как такая хрень вообще происходит?
Дальше ты переводишь все проекты на эту абстракцию и спокойненько работаешь еще 20 лет взяв еще 100500 заказов.
Где-то после этой фразы всё начинает идти не так, как в мечтах. Начинают появляться клиенты, которым нужно обязательно какая-нибудь распространённая ORM вместо вашего поделия, т.к. им неохота становиться зависимым от вас. А ещё через пару лет больше никто к вам за заказами не ходит, кроме всяких лохов. Ну и у вам остаётся лишь доить старых клиентов, если они ещё не поняли, что надо всё переписать на распространённые фреймворки.
В результате у тебя появился несопровождаемый монстр с миллионом зависимостей
Через 20 лет появится в любом случае.
Вот недавно попался проект. Ни к одной строчке никаких претензий, всё по правилам. Но понять, как работает практически невозможно.
Так как для этого нужно знать как работает вся система в целом. Ну или хотя-бы раз увидеть как всё работает вместе.
Начинают появляться клиенты, которым нужно обязательно какая-нибудь распространённая ORM вместо вашего поделия, т.к. им неохота становиться зависимым от вас.
Во-первых, от ORM тоже можно абстрагироваться тем же UnitOfWork.
Во-вторых, я совсем не уверен, что клиенту важно, работает ли под капотом EF или NHibernate или что-то другое. Какая БД под капотом - это важно, т.к. лицензии на SQLite и Oracle стоят разных денег :) И сами БД имеют разную производительность.
ORM - это инструмент. Ты говоришь автомеханику какими инструментами он должен пользоваться при починке твоей машины? :) Вот и тут тоже самое.
------
Может Я тебя удивлю, но в европах иногда встречается специфика - например, могут потребовать чтобы аккумулятор твоей автомашины зарядили током от определенной электростанции. 
И, кстати, да - уже лет 15-ть как надо интересоваться есть ли механика необходимые инструменты...
Во-первых, от ORM тоже можно абстрагироваться тем же UnitOfWork.
В нормальных ормах (EF) это уже давно встроено. Городить юнит над юнитом и прочие архитектурные излишества по огораживанию - нафиг.
Но я вас прекрасно понимаю. - Хочется сидеть со своими костылями до пенсии, быть альфакодером в отдельно взятой конторе, шамкать старческим ртом что-то нечленораздельное на митингах, смотря, как джуны заглядывают вам в рот... Не выйдет. Мы придём и сотрём вас с лица земли!
))
Во-вторых, я совсем не уверен, что клиенту важно, работает ли под капотом EF или NHibernate или что-то другое. Какая БД под капотом - это важно, т.к. лицензии на SQLite и Oracle стоят разных денег :) И сами БД имеют разную производительность.
ORM - это инструмент. Ты говоришь автомеханику какими инструментами он должен пользоваться при починке твоей машины? :) Вот и тут тоже самое.
Лохам - да, неважно. Встречали вакухи, где надо знать распространённые фреймворки, а за знание нераспространённых в лучшем случае пропустят мимо ушей? Но могут и поржать.
Через 20 лет появится в любом случае.Зависит от того, как создается и поддерживается код.
Программист, надеющийся, что за 20 лет всё поддерживается и обновляется - наивный лох.
Может Я тебя удивлю, но в европах иногда встречается специфика - например, могут потребовать чтобы аккумулятор твоей автомашины зарядили током от определенной электростанции.
"У Мура своё кино" (С)
...где хаты от 12к в месяц, дома от 24.
В нормальных ормах (EF) это уже давно встроено.
Можно пример, чего там в ЕФ встроено?
Лохам - да, неважно. Встречали вакухи, где надо знать распространённые фреймворки, а за знание нераспространённых в лучшем случае пропустят мимо ушей? Но могут и поржать.
К чему тут высер о вакухах?
речь же о заказчике, тут я с оратором выше согласен - они как правило и знать ни о каких ОРМах не знают.
Во-первых, от ORM тоже можно абстрагироваться тем же UnitOfWork.
я может сейчас скажу очень не популярное мнение, но манал я уже все эти абстрагирования.
Есть у нас один такой проект, сделанный по методичке евангелистов - это полный П.
Нужна тебя новая функция GetCustomerById
Сначала ты добавляешь её в три интерфейса: IcustomerDistributedService, Icustomerservice и IcustomerRepository. Затем пишешь в трех местах реализацию.
Если есть mock repository и сервисы, то не забываешь дописать и там.
Далее - у customer появилось новое поле цвет ногтей. Объявляешь его в классе customer(он у нас соответствует таблице в БД), затем в Customer DataTransferObject, иначе ведь не православно Entity классы использовать в presentation layer.
Не забыть прописать присвоения в конвертации entity => DTO и обратно.
И надо было так упарываться?
Брат твой коня в канаве доедает.
какой unitOfWork встроен в Entity Framework?
Кто-то тут недавно хвастался, что с искуственным идиотом беседы ведёт. Первые же ссылки в Яндексе по "какой unitOfWork встроен в Entity Framework?" дают что-то подобное. Волчара позорный!
))
Может Я тебя удивлю, но в европах иногда встречается специфика - например, могут потребовать чтобы аккумулятор твоей автомашины зарядили током от определенной электростанции.
Да, ты меня удивил :) Я еще не видел, чтобы кто-то заряжал аккумуляторы на автосервисе :) Просто покупают новый, а старый сдают на утилизацию :)
И, кстати, да - уже лет 15-ть как надо интересоваться есть ли механика необходимые инструменты...
Не знаю в какой дыре ты живешь, но я никогда этим не интересовался :) Если нет инструментов, то просто говорят "мы не можему это починить" и все. Я про активно инструментарием механика не интересуюсь :)
Может Я тебя удивлю, но в европах иногда встречается специфика - например, могут потребовать чтобы аккумулятор твоей автомашины зарядили током от определенной электростанции.Да, ты меня удивил :) Я еще не видел, чтобы кто-то заряжал аррумуляторы на автосервисе :) Просто покупают новый, а старый сдают на утилизацию :)
У семизнаков свои причуды. ¯\_(ツ)_/¯
В нормальных ормах (EF) это уже давно встроено. Городить юнит над юнитом и прочие архитектурные излишества по огораживанию - нафиг.
Нафиг или нет, ты будешь говорить, когда один клиент начнет требовать EF, другой NHibernate и тебе придется дублировать код. А после дубля кода тебе сообщат об ошибке и эту ошибку тебе придется фиксить в 2-х местах... А разных ORM много.
Но я вас прекрасно понимаю.
Нихрена ты не понимаешь :) Ты просто дальше собственного носа не видишь :)
Лохам - да, неважно.
Лохи тут не причем. Заказчику надо, чтобы софт стабильно работал, его не интересует ни архитектура, ни используемый инструментарий. Собственно говоря, техническое задание - это набор фич и критериев приемки рачего кода. В ТЗ описывается "ЧТО" надо сделать, а не "КАК".
Встречали вакухи, где надо знать распространённые фреймворки, а за знание нераспространённых в лучшем случае пропустят мимо ушей? Но могут и поржать.
Не понимаю о чем ты говоришь. Кто над кем может поржать?