А как такая хрень вообще происходит?
https://jimmybogard.com/automappers-design-philosophy/
So we adopted the name "view model" to describe our models in MVC - these were models specifically designed for a view.
We started this long-running project with a few rules for our view models:
Т.е. как я понимаю, чел с командой делали сайт на MVC, потом забили, и начали "долгий" проект по созданию своей либы. А кто банкет оплачивал? Изначальный инвестор сайта на MVC? А ему оно зачем, что целая команда теперь вместо сайта занимается общественно полезным трудом, но не приносит ему денег?
Просто интересно, откуда такие челы берутся, которые могут полностью посвятить себя долгому общественно полезному труду, написанию блогов, "филосовия моей библиотеки" и всё такое. При этом в деньгах, судя по всему, особо не нуждаются, поэтому на создание сайтов для дядей могут подзабить.
Там вообще прикол, судя по описанию. Они делали сайт. Ничего не сделали. Решили делать тулзу. Увязли в ней.
Дедлайны? Требования бизнеса? - Пофиг всё, мы решаем философские вопросы и делаем максимально универсальные решения.
Вот скажите, по какому месту пойдёт весь ваш аджайл и прочий скрам, если вы будете делать "few dozens" экранов, а потом выкинете всё в помойку и приметесь заниматься совсем другими вещами?
А ему оно зачем, что целая команда теперь вместо сайта занимается общественно полезным трудом, но не приносит ему денег?
Это напивается PR. Труд разрекламированного человека стоит гораздо дороже :) Кроме того, известному человеку гораздо проще найти интересный проект. А может быть даже 2 и больше параллельных проекта. В результате этот чувак менеджерит тех, у кого на блоги нет времени :)
Да, но до этого он как-то уговорил своих боссов, чтобы целая команда, включая архитектора (т.е. там зарплаты явно шестизначные были даже на то время), забила на сайт и делала фреймворк. Причём фреймворк не очень-то и значимый - узкая направленность, куча ограничений. Бложить много кто может, но это лишь внешнее проявление. А внутри он как-то свалил на кого-то всю основную работу, а сам занялся своим проектом за счёт работодателя.
))
Насчёт узкой направленности - заметьте, что спустя примерно 10 лет (если начали они на заре ASP.NET MVC) он пишет статью, где объясняет, что его не так поняли, и почему его автомаппер не годится во вмогих случаях. Но первоначальный-то хайп и пиар обеспечен. Спустя время другие люди понаделали других мапперов - лучше и быстрее. Но они уже не такие известные, как этот автомаппер и его создатель.
Да, но до этого он как-то уговорил своих боссов, чтобы целая команда, включая архитектора (т.е. там зарплаты явно шестизначные были даже на то время), забила на сайт и делала фреймворк.
Во-первых, почему ты думаешь, что он кого-то уговаривал?
Во-вторых, на фирмах часто делаются различные фреймворки под свои нужды.
В-третьих, он мог взять какую-то идею с работы и начать реализовывать ее замостоятельно. Уже после того, как набил какие-то шишки на работе.
Бложить много кто может
Бложить может нало кто :) А хорошо бложить могут еще меньше.
А внутри он как-то свалил на кого-то всю основную работу, а сам занялся своим проектом за счёт работодателя.
С чего ты это взял?
Он же сам там пишет, что они делали сайт, не получалось, стали делать фреймворк. А кто сайт делал?
Вы где-нибудь в фирме, делающей сайты на заказ, видели, чтобы попробовали сделать "несколько дюжин" экранов (я так понимаю, он имел ввиду представлений, т.е. страниц сайта) - не получилось. Стали переделывать - не получилось. Тогда решили сделать фреймворк, а потом делать сайт. Ещё где-то перед решением сделать фреймворк должен пройти дедлайн сдачи сайта заказчику. Но всё норм - челы переключились на другую задачу.
Он же сам там пишет, что они делали сайт, не получалось, стали делать фреймворк. А кто сайт делал?
Если стали делать фреймворк, то это не значит, что работа над сайтом остановилась.
Вы где-нибудь в фирме, делающей сайты на заказ
Я никогда не работал в фирме, которая делайт сайты :) На заказ или еще как-то.
Тогда решили сделать фреймворк, а потом делать сайт.
Когда-то давно слышал, что студия Лебедева пошла этим путем - они делают сайты на каком-то своем самописном фреймворке. С точки зрения бизнеса это очень правильное решение. ИМХО.
Ещё где-то перед решением сделать фреймворк должен пройти дедлайн сдачи сайта заказчику. Но всё норм - челы переключились на другую задачу.
Сайты заказчику можно делать и параллельно пилить фреймворк. А после того, как фреймворк будет готов, можно будет мигрировать имеющиеся сайты. Как будто ты никогда не работал в фирмах, где идет работа по нескольким направлениям :D
Когда-то давно слышал, что студия Лебедева пошла этим путем - они делают сайты на каком-то своем самописном фреймворке. С точки зрения бизнеса это очень правильное решение. ИМХО.
Я бы у таких не заказывал. Голимый вендор лок ин. Одно дело, когда всякие Триттеры или Майкрософты так делают - они большие, и все юзают их фреймворки. А кто такой Лебедев и его студия с точки зрения мирового айти? - Их не существует. Потому потом, когда я пойду с их проектом к другим, те скажут, что тут какая-то хрень самописная - у кого делали, к тем и идите.
Обычно в фирмах, где на потоке делают сайты (проги, сервисы и т.д.) на заказ, нет команд, делающих фреймворки. Это тупо галеры по заколачиванию бабла, перерабатывающие людей и нервы в грязные шелестящие бумажки.
Но в принципе да - непонятно, что у них за ситуация была.
Короче, челу повезло - не приседали беспрестанно на голову "когда сделано будет? - следующие клиенты ждут", разрешили заниматься своим проектом и пиариться на нём. Ещё и бабла за это отваливают. Работа мечты.
Обычно в фирмах, где на потоке делают сайты (проги, сервисы и т.д.) на заказ, нет команд, делающих фреймворки. Это тупо галеры по заколачиванию бабла, перерабатывающие людей и нервы в грязные шелестящие бумажки.
Ошибаешься :) Как раз там, где делают сайты (проги, сервисы и т.д.) на
заказ и нужен свой фреймворк или как минимум библиотека.
Связано это с тем, что заказы плюс-минус одинаковые и гораздо дешевле составить сайт из уже готовых блоков, чем каждый раз изобретать велосипед и потом еще этот велосипед поддерживать.
Я одно время работал в конторе, которая делала приложения на заказ. Конечно в каждой программе было что-то свое, но 80% рабочего кода бралось из существующей библиотеки (это было в 2001 году и писали мы тогда на ANSI C для ручных сканнеров). Потом, к 2004 году когда на аппаратах стали ставить Windows CE, мы портировали библиотеку на C++. Думаю, что сейчас у них там уже все портированно на C# :)
Связано это с тем, что заказы плюс-минус одинаковые и гораздо дешевле составить сайт из уже готовых блоков, чем каждый раз изобретать велосипед и потом еще этот велосипед поддерживать.
Ваш собственный фреймворк и будет таким велосипедом.
нужен свой фреймворк или как минимум библиотека.
Это если есть отдельные челы, которые сидят и постоянно портируют, актуализируют, обновляют, добавляют, убирают и прочее. И желательно больше ничем серьёзно не занимаются.
Я тоже как-то собирал отдельные интересные и нужные мне куски кода в свою библиотеку. Пока кода было мало и он был актуальный - ещё катило. Через несколько лет либа разраслась и стала во многом неактуальной - старые подходы, а то и вовсе не работало. И мне теперь сидеть и несколько дней править всё? А ещё через несколько лет править придётся пару недель. Хорошо, что постепенно часть кода из моей либы стала не нужна - появились такие же или похожие функции во фреймворке из коробке или в сторонних либах.
Ваш собственный фреймворк и будет таким велосипедом.
Нет, таким велосипедом будет зоопарк технологий.
Гораздо проще поддерживать один собственный фреймворк, чем искать специалистов по десятку разных технологий.
Это если есть отдельные челы, которые сидят и постоянно портируют, актуализируют, обновляют, добавляют, убирают и прочее. И желательно больше ничем серьёзно не занимаются.
Это зависит :) У нас в актуальном проекте платформенные компоненты может менять любой разработчик по мере надобности. Но чем ниже компонента, тем больше нужно согласовывать изменения с архитектором.
Гораздо проще поддерживать один собственный фреймворк, чем искать специалистов по десятку разных технологий.
В моменте. На длинной дистанции - нет. И, ещё раз - зависит от размера фирмы. Большим (грубо говоря, 100+ сотрудников) - да, иногда лучше свой фреймворк иметь. Мелким и средним - только время зря терять.
У вас есть опыт поддержки собственного фреймворка? Я вот, как говорил, либку свою имел - задолбался там подновлять и поддерживать. А тут целый фреймворк.
У вас есть опыт поддержки собственного фреймворка? Я вот, как говорил, либку свою имел - задолбался там подновлять и поддерживать. А тут целый фреймворк.
Мы с командой в 5 разработчиков очень успешно использовали и поддерживали функциональную библиотеку. И делали это довольно успешно.
Собственно говоря, всегда можно пойти несколькими путями.
Например, ты у тебя в проектах есть взаимодействие с БД и 100500 клиентов. При этом часть клиентов требуют Oracle, другие MS SQL, MySQL, третьим достаточно SQLite итд. И вот, ты живешь в 2000 году и у тебя есть выбор - либо в каждом проекте напрямую работать с БД, либо сделать абстракцию. И скорее всего ты сделаешь абстракцию :) И придется тебе в 2000 году писать свою абстракцию, т.к. никаких EF еще и близко не существует. И вот, через год планирования у тебя есть готовый модуль. Дальше ты переводишь все проекты на эту абстракцию и спокойненько работаешь еще 20 лет взяв еще 100500 заказов. И тут приходит к тебе Алекс и говорит "все это херня, человечество изобрело EF, давайте теперь использовать EF". И тут встает вопрос, а готов ли Алекс перевести 100500 заказов (ну ок, меньше, т.к. не все нуждаются в поддержке) со старого подхода на EF? И, что самое главное, готов ли Алекс взять на себя ответственность за то, что этот перевод будет успешным? Есть ли у этого перехода бизнес необходимость? Если нет, то Алекс идет работать с кодом из 2000 года :)
А то, что ты задолбался подновлять и поддерживать свою либку, так это, скорее всего, из-за того, что ты не пытался максимально ее использовать с минимальными изменениями. Грубо говоря, сделал либку, добавил туда
каких-нибудь контейнеров, потом добавили в стандарт стл - ты в половине мест заменил свои контейнеры на стл (там, где часто пользовался), а в других местах не менял. Потом появился буст и ты еще немного расширил свою библиотеку. В результате у тебя появился несопровождаемый монстр с миллионом зависимостей :)
Дальше ты переводишь все проекты на эту абстракцию и спокойненько работаешь еще 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 много.
Но я вас прекрасно понимаю.
Нихрена ты не понимаешь :) Ты просто дальше собственного носа не видишь :)
Лохам - да, неважно.
Лохи тут не причем. Заказчику надо, чтобы софт стабильно работал, его не интересует ни архитектура, ни используемый инструментарий. Собственно говоря, техническое задание - это набор фич и критериев приемки рачего кода. В ТЗ описывается "ЧТО" надо сделать, а не "КАК".
Встречали вакухи, где надо знать распространённые фреймворки, а за знание нераспространённых в лучшем случае пропустят мимо ушей? Но могут и поржать.
Не понимаю о чем ты говоришь. Кто над кем может поржать?
Программист, надеющийся, что за 20 лет всё поддерживается и обновляется - наивный лох.
Все меняется и технологии в том числе :) Но вместе с тем есть вещи, которые не меняются десятилетиями и никто их не будет менять просто из-за того, что в этом нет бизнесовой необходимости.
Именно бизнес необходимость является триггером для изменений.
Вместе с тем, программист, который внядряет каждую новую технологию - мягко выражаясь недальновидный. А если новая технология внедряется где-то локально, а везде в остальных местах все работает по старому, то это вообще трындец.
Зависит от того, как создается и поддерживается код.
Для обозримого промежутка времени, в каких то случаях, еще можно согласиться.
Но за 20 лет столько всего изменится, что никакие крутые теории не спасут.
Особенно, когда всё начиналось с гаража х лет назад.
я может сейчас скажу очень не популярное мнение, но манал я уже все эти абстрагирования.
Манал или не манал, а абстракции помогают жить :) Во-первых, позволяют строить приложение из "кирпичиков". При этом из заменяемых кирпичиков. Во-вторых, позмоляют тестировать код без лишних зависимостей.
Нужна тебя новая функция GetCustomerByIdНу т.е. и без интерфейсов тебе пришлось бы добавить реализацию в трех местах :D
Сначала ты добавляешь её в три интерфейса: IcustomerDistributedService, Icustomerservice и IcustomerRepository. Затем пишешь в трех местах реализацию.
А так, ты видишь, что возможно у тебя есть проблема с архитектурой... может быть имело бы смысл выделить customer'а в отдельный сервис, добавить функцию GetCustomerById в ICustomerService, а твоих IcustomerDistributedService, Icustomerservice и IcustomerRepository работать через новый ICustomerService....
И надо было так упарываться?
Радикализм до добра не доводит :)
насчёт 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)
Я боюсь, если кто-то решит мигрировать на другой ОРМ, нам всем станет очень больно.
У семизнаков свои причуды. ¯\_(ツ)_/¯
За при чем тут семизнаки? Если аккумулятор не держит заряд, то это мертвый аккумулятор :) А так, он самостоятельно заряжается при езде от генератора. Да и стоят эти аккумуляторы около 100Евро.
Если речь об электромашинах, то их никто на сервисе не заряжает.
в моём понимании мок классы реализуют интерфейсы, т.о. проект не скомпилируется, пока в моках отсутствуют новые функции.
Это если ты сам реализуешь мок классы. Если используешь фреймфорк (например Moq или NSubstitute), то все скомпилируется.
Ну т.е. и без интерфейсов тебе пришлось бы добавить реализацию в трех местах :D
А так, ты видишь, что возможно у тебя есть проблема с архитектурой... может быть имело бы смысл выделить customer'а в отдельный сервис, добавить функцию GetCustomerById в ICustomerService, а твоих IcustomerDistributedService, Icustomerservice и IcustomerRepository работать через новый ICustomerService....
Да моя проблема это не (с)только интерфейсы, сколько дома ненужная цепочка из двух сервисов и репозитории. Они просто тупо друг Друга вызывают.
Уж не знаю, по какой методичке тот архитектор учился.
Но за 20 лет столько всего изменится, что никакие крутые теории не спасут.
Особенно, когда всё начиналось с гаража х лет назад.
Я сейчас работаю в проекте, который начался боьше 20 лет тому назад. И у нас до сих пор есть куски кода, которые уже 20 лет работают. И уже хрен знает сколько лет в проекте используется оракл, черти сколько лет тому назад был спроектирован слой взаимодействия с БД и за последние 2 года там было пара расширений и пара багфиксов.
Возможно когда-нибудь придется все это выбросить и перейти на что-то другое, но сейчас этот код работает, проблем не доставляет и нет ни одной причины его выбрасывать.
там было пара расширений
У каждого своя специфика. У нас так постоянно что то нужно.
А как глянешь расширения написанные по заказу, так волосы шевелятся. Но да, их никто не трогает потому что работают.
и нет ни одной причины его выбрасывать.
Ну если можно жить с до сих пор с NET 2.0,то можно и не выбрасывать.
А как глянешь расширения написанные по заказу, так волосы шевелятся
Может быть проблема в том, что у вас нет человека, который бьет по рукам? :)
Ну если можно жить с до сих пор с NET 2.0,то можно и не выбрасывать.
Только что перешли на .Net 4.8
Когда будем переходить дальше - вопрос. При этом в первую очередь вопрос технический. Если надо будет много переписывать, то будут оттягивать переход максимально долго. Т.к. новый код - это всегда риск, а у нас очень чувствительная тема и ошибки могут очень дорого стоить....
Нафиг или нет, ты будешь говорить, когда один клиент начнет требовать EF, другой NHibernate и тебе придется дублировать код. А после дубля кода тебе сообщат об ошибке и эту ошибку тебе придется фиксить в 2-х местах... А разных ORM много.
Значит, у вас есть команды, специализирующиеся по ормам. Либо челы, знающие несколько ормов. Либо вы берёте только те проекты, по технологиям которых имеете спецов.
Мы как бы всё ещё говорим о конторе, клепающей на заказ сайты и прочие проекты, а не поддерживающей своё костыльное болото десятилетиями? Если вы не какой-нибудь SAP или Твиттер, то и свой фреймворк, и продукт на его основе, и команды поддержки для всех клиентов вы навряд ли потянете. Впрочем, уже по второму кругу пошло обсуждение.
ненужная цепочка из двух сервисов и репозитории. Они просто тупо друг Друга вызывают.
Уж не знаю, по какой методичке тот архитектор учился.
Очень похоже на DDD. https://stackoverflow.com/questions/4159812/services-and-r...
User Interface Layer -> IcustomerDistributedService (внешний интерфейс к сервису), Application Layer -> Icustomerservice и Infrastructure Layer -> реализация ICustomerRepository
И да, это имеет смысл. Лучше с самого начала добавить "тупой" сервис, который "тупо вызывает репозиторий", чем через два года пытаться разодрать монструозный репозиторий на собственно репозиторий и сервис. И пытаться понять что делать с сервисами, которые вызывались напрямую из этого репозитория и как убирать тучу обратных связей.
Сервис может найти какую-то сущность, изменить её, вызвать другой сервис, с полученными от него данными найти ещё пару объектов в репозитории и вернуть их.
Как вам помог компилятор "Если есть mock repository и сервисы, то не забываешь дописать и там."?в моём понимании мок классы реализуют интерфейсы, т.о. проект не скомпилируется, пока в моках отсутствуют новые функции.
Тогда почему вы боитесь забыть, если за вас всё равно напомнят? Если напомнят, значит всё в порядке. Проблемы нет.
Не забыть прописать присвоения в конвертации entity => DTO и обратно.Зачем? Когда это делается почти автоматом маппером.
Правда, в маппере надо инструкции добавить, конфиги обновить, или что у него там. Так что не всё ли равно, через маппер всё делать или вручную в конвертерах. Что там несколько строк, что там несколько строк.
Если вы не какой-нибудь SAP или Твиттер, то и свой фреймворк, и продукт на его основе, и команды поддержки для всех клиентов вы навряд ли потянете. Впрочем, уже по второму кругу пошло обсуждение.
В нулевых я работал на фирме, которая делала сайты. И у нее - сюрприз! - был свой самописный CMS. Который мы развивали. А сайты делались на этом CMS-е. Клиентов было что-то в районе 40-50 фирм. Никаким сапом там не пахло. Нас в бекэнде было 3 человека. И тянули, и развивали и для клиентов новые свистелки реализовывали. Так что помолчи уже, за умного сойдёшь.
насчёт 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 тоже на машинах работает?
В чём проблема? У меня на старой работе тоже делали софт для машин. Подключаешься к автомобильному компу и шуруешь там. Мы газовали, крутя крутилку в интерфейсе нашей программы.
Либо можно просто сделать абстракцию, которая будет независима от ОРМа и тогда можно брать все проекты :)
Зависит от качества и уровня проработки этой вашей абстракции. Чтобы использовать все возможности ормов (не то что одной, а хотя бы нескольких), да ещё обновлять свою абстракцию с обновлениями ормов, абстракция должна быть сложнее любого этого орма по архитектуре. Ну и соответствующая команда на эту бандуру.
А если тяп-ляп, лишь бы простые команды поддерживала, то можно, конечно, и на коленке слепить кусок костыля.
UI с изменениями. Пару лет назад начали мигрировать UI с WinForms на WPF, сейчас вот закончили этот процесс.
Когда МС уже как несколько лет забила на ВПФ, вы на него закончили мигрировать. Начинайте сразу на Blazor и MAUI - как раз к их устареванию успеете... Зато свой фреймворк!!!
ты молодёжь попробуй заставь писать pl/sql
Да и это пришлось бы на каждый пук писать свою хранимку.
А с инклудами вообще можешь забыть.
И тут такой вылезает Dynamic LINQ весь в белом...
Нет уж лучше так, чем 100500 методов типа
GetCustomerByIdWithAdress
GetCustomerByNumberWithOrders
GetOrdersByDateWithCustomers
И т.д.
Не, ну если так всё запущено, и на каждый чих метод делать... Просто пристрелите чувака, который нагородил вам эти абстракции, и юзайте обычный EF.
В чём проблема? У меня на старой работе тоже делали софт для машин. Подключаешься к автомобильному компу и шуруешь там. Мы газовали, крутя крутилку в интерфейсе нашей программы.
Я этот вопрос задал, чтобы понять, почему не решили перейти сразу на веб приложение.
тут такой вылезает Dynamic LINQ весь в белом.
ты накуренный чтоли? Какой динамик линк в pl/sql? Все наши требования мы и без него в EF могли реализовать.
Начинайте сразу на Blazor и MAUI - как раз к их устареванию успеете...
Зачем там Blazor или MAUI? Веба у нас и близко нет, необходимости использовать мобильные устройства тоже. В крупных проектах решения принимаются и исполныются очень долго. Никто не будет срываться с места и переписывать все под MAUI только из-за того, что это новый фреймворк. Это дорого и неэффективно.
Не, ну если так всё запущено, и на каждый чих метод делать... Просто пристрелите чувака, который нагородил вам эти абстракции, и юзайте обычный EFчувак уволился уже.
В моём проекте я и делаю как мне удобно, а в том хоть трава не расти
Тогда насите броник сами, пока не уволитесь. ))
Как сериализовать запрос с пользовательскими настройками (он его сам конструирует), сохранить где-нибудь и потом опять десериализовать? Желательно в одну-две строки
Опять ты со своими сериализиванными запросами.
Я в душе не ебу, что это.
И пользователи у нас никакие запросы не конструируют.
пользователи у нас никакие запросы не конструируют.
Держите их в ежовых руковицах?
Ладно, вот для расслабиться.
и свой фреймворк, и продукт на его основе, и команды поддержки для всех клиентов вы навряд ли потянете.
-----
И когда же ты глупости нести перестанешь?
Лет 10-ть назад трудился в маленькой шаражке лепящей вэб на... ASP. На чистом ASP.
Том самом, где билли в образцах пишет
Connection connection = new Connection connectionString, connectionMode
Connection.Open
...
Connection.Close
Страничка лепилась неделю и более.
Просто упаковал общий код в класс и заставил писать юниты по -таблично, тестить юниты и из оттесченого собирать странички... где-то часов 6 потратил.
В разработке все упростилось и сократилось до нескольких часов.
А ты говоришь - врядли потянете... чушь, как обычно...
и для пачки методов с изъёпистыми запросами
------
1. Пачка методов видится разом по схеме базы данных. Много раз показывал простой фокус - спрашивал, соответствует ли база тех.заданию, печатал схему и по ней писал код. Без тех.задания. На 98% код был правильным. Оставшиеся 2% - налажал ДБА.
2. ВСЕ необходимые запросы без проблем определяются по схеме базы. Причем там все настолько примитивно, что даже простой автомат справляется.
а UI тоже на машинах работает?
------
А что тебя в этом удивляет? Или ты просто никогда не видел как оборудуется рабочее место на производстве? Там втыкается обычный писюк и управление струячится по ком/усб портам...
Нормальный десктопный UI и отсылка протокола/отчета на сервер.
Нах там вэб? все локально...
Лет 10-ть назад трудился в маленькой шаражке лепящей вэб на... ASP. На чистом ASP.
Том самом, где билли в образцах пишет
Connection connection = new Connection connectionString, connectionMode
Connection.Open
...
Connection.Close
Страничка лепилась неделю и более.
Просто упаковал общий код в класс и заставил писать юниты по -таблично, тестить юниты и из оттесченого собирать странички... где-то часов 6 потратил.
В разработке все упростилось и сократилось до нескольких часов.
10 лет назад уже вовсю был раскручен ASP.NET MVC, а труп Сильверлайта даже не сильно вонял. Да даже EF был уже вполне хорош... Нет, если вы тогда были вынуждены писать на старом ASP, а клиент не хотел переписывать на что-то посовременнее, то это конечно ваша беда. И там можно было городить любые свои костыли и "фреймворки". Все давно похоронили это оно мамонта и всем плевать - за пределы этой шаражки это никуда не уйдёт.
Но... насчёт "потабличных юнитов" - а если надо заюзать джойны? Создаются юниты на все комбинации джойнов?
Как сериализовать запрос с пользовательскими настройками------
Тупо в лоб - вызвать метод ToSql()!
Похоже, вы забыли другую часть фразы - "а обратно?".
И я не сказал всех условий (прямо как вы) - сериализовать надо из UI. Вот есть в UI кучка объектов с фильтрами, их надо в скуль. Но напрямую нельзя - отцы запрещают, говорят про опасность всяких инъекций и прочее.
С динамичным линком вы можете написать запрос из строки. А строку сконкатенировать из условных строк-фильтров в вашем UI. Например, фильтр-строка "contains" может быть трансформирована в линк-метод Contains и обратно. А строка - лёгкая сериализация запроса. Поэтому либа Radzen простая и лёгкая, т.к. основана на DLINQ. Без этого им бы пришлось писать кучу своих конвертеров.
А что, есть такие
-----
Поверь - есть и много. Скорее их даже большинство.
Хех, я тоже удивился, когда тут в Германии таких увидел. Получается, что все эти "евангелисты" со своими проповедями "как надо писать код" мимо большинства реальной разработки проходят. Да что там - даже сами эти евангелисты зачастую плюют на свои же принципы, если стоит дедлайн и надо быстро на коленке. Но на собесах все как один сношают по методичкам.
а UI тоже на машинах работает?
------
А что тебя в этом удивляет? Или ты просто никогда не видел как оборудуется рабочее место на производстве? Там втыкается обычный писюк и управление струячится по ком/усб портам...
Нормальный десктопный UI и отсылка протокола/отчета на сервер.
Нах там вэб? все локально...
На одной фабрике, где я был, UI был на WPF, на другой - самописные веб-контролы, а теперь я переписываю на тот же веб, но уже Blazor. Ещё у них есть мобильные терминалы в виде PDA на виндовс мобайл. Но если немного заморочиться, то на Blazor я могу им написать автоматически адаптирующийся UI под маленькие экраны. В основном через Bootstrap.
весь в белом...
------
...обламывается на неподдерживаемой версии Оракла.
DLINQ не про Оракл. Он вообще не про ДБ. Это прослойка между LINQ и кодом. Его дело - запросы и их сериализация. Ну и там по мелочи накрутили вокруг него. Вы по ссылке-то ходили, что я дал?
На одной фабрике, где я был, UI был на WPF, на другой - самописные веб-контролы
Но всё крутилось на машинах с виндами. Не так давно фотка в новостях мелькала - Кук на фабрике, производящей Айфоны. На конвейере стоят терминалы с Виндой. Терминалов на Макосях не видно. Оно и понятно - МС собаку на интерфейсах и фреймворках съела. А Эппл с линуксятней - просто понторезки. Только одни - понторезка для богатых дурачков, а другие - для бедных.
Оно и понятно - МС собаку на интерфейсах и фреймворках съела.
Хто-хто? Мелкомягкие? Прущие чуть больше чем всё из *nix и *bsd систем? Которые сначала просрали интернет, а потом за 25 лет так и не смогли сделать приличный браузер? Которые не могут ни один стандарт реализовать? Всё у них через жопу и со своими свистоперделками. Которые юникод до 7й винды поддерживали через жопу и до сих пор упорно лепят BOM во все UTF-8 файлы? Даже в xml, ломая их. Потому как по стандарту (который тупорылые мелкософтовцы тоже нихрена не поняли) любой xml файл начинается с <, пробела, таба или CR/LF. Из-за чего специально для виндусятнигов приходилось корячить парсеры. Которые даже не смогли понять что C в аббревиатуре CSV означает "comma". Нее, это у всего мира запятыми отделять будем, а мы, дегенераты, будем отделять "разделителем в списке".
В общем, не смешите мои тапочки. В части интерфейсов (не гуёв) фирмы дерьмовее мелкомягких не существует.
А Эппл с линуксятней - просто понторезки. Только одни - понторезка для богатых дурачков, а другие - для бедных.
Ага. Именно поэтому примерно 80% интернет-серверов в мире работают на юниксоподобных системах. Все они дураки. Один ты умный. Когда ж ты уже в майами свалишь, а?
ок. А если учесть, что asp.net mvc это presentation layer?
Presentation Layer не означает, что это UI.
Вообще говоря, несколько разных Views могут взаимодействовать с одним Controller'ом (или View Model).
Насколько я понимаю, Controller (или View Model) - это и есть та абстракция, котороя отделяет бизнес логику от представления.
а потом за 25 лет так и не смогли сделать приличный браузер?
ИЕ в своё время был хорошим браузером. Ничего лучше не было до появления Оперы 7-8 примерно. Потом сдулся, конечно. Но в своё время ИЕ6 был просто революционным.
Которые даже не смогли понять что C в аббревиатуре CSV означает "comma". Нее, это у всего мира запятыми отделять будем, а мы, дегенераты, будем отделять "разделителем в списке".
И правильно сделали. А то единоличники, создавшие аббревиатуру CSV, не догадывались, что кроме английского есть и другие языки, где десятичный разделитель - запятая, а не удобная англоговорящим точка. Или что я хочу хранить там куски фраз со знаками преминания.
В части интерфейсов (не гуёв) фирмы дерьмовее мелкомягких не существует.
Интерфейс Виндовс 95-2000 вообще эталонный по внешнему виду. Линускойды создавали всякие понтовые игрушки в UI, но беда их в том, что они всегда шли кто в лес, кто по дрова - единого стандарта не было. Каждый лепил как ему нравится, в результате в каждой программе надо было привыкать к образу мыслей её создателя. У МС же были довольно единые стандарты, которых они долго придерживались, в результате все проги работали примерно одинаково и имели узнаваемые меню. Что, конечно же, не нравилось веб-мальчикам, вышедшим частично из линуксоидов (то-то скриптизёры через одного на яблоках и линуксах сидят) - им хотелось, чтобы меню каждого сайта выглядело по-разному, и чтобы любой пользователь разбирался с нуля, где там у них что и как всё работает.
Ага. Именно поэтому примерно 80% интернет-серверов в мире работают на юниксоподобных системах. Все они дураки.
Они крохоборы. Просто не хотят платить за лицензии. Если бы в поездах можно было ездить бесплатно или за очень маленькую сумму от обычного билета, но лишь сидя на полу, но все полы были бы забиты такими халявщиками, экономящими малую деньгу даже не смотря на все неудобства.
Многие стандарты МС поддерживает по-своему не потому, что они тупые (они как раз умнее многих), а чтобы подмять их под себя.
Непонятно, почему для схемы документа с целым одним условным значком придумали аж целый формат. А с двумя значками - уже другой формат? Пока до какого-нибудь XML дойдём, уже тыщу разных форматов придумаем. Хотя, судя по истории, этому формату уже полвека, если не больше. Тогда да - в то время и это было достаточно сложным. Парсить всякие XML, JSON, если бы они существовали в то время, не было ни мощностей, ни памяти.
В других вообще ничего нормального не было. Да и этих других тоже толком не было. Более того, некоторые браузеры (если не все) были платные - та же Опера. А Ишак, насколько помню, всегда шёл в комплекте забесплатно. Вся критика ИЕ6 - только спустя несколько лет после его повяления и на фоне развития других браузеров и неразвития ИЕ.
В других вообще ничего нормального не было. Да и этих других тоже толком не былоСтранно, как то мимо прошло, всегда был нормальный браузер и точно не ИЕ. С ИЕ пришлось по работе столкнутся и кроме проблем с ним, ничего не помню.
А с какого года вы браузерами пользуетесь? И какие были?
Спрошу здесь, т.к. в теме про налоги спецов нету. Речь про Эльстер, чтобы налоговую заполнить. Они предлагают скачать сертификат и установить себе, чтобы у них зарегаться и заполнять налоговую. Кто-нибудь ставил? Я что-то не совсем вкурил - это теперь будет один из корневых сертификатов на компе, или что? Или это что-то типа цифровой подписи для залогинивания у них на сайте?
Ещё предлагают через электронный паспорт логиниться, но для этого надо на телефо ставить приложение паспорта. Мне ни тот, ни другой варианты не очень нравятся.
Вобщем, кто-то юзает этот Эльстер с логином через сертификат, или цифровой паспорт с приложухой на телефоне?
Ещё предлагают через электронный паспорт логиниться, но для этого надо на телефо ставить приложение паспорта. Мне ни тот, ни другой варианты не очень нравятся.Не обязательно их приложение
Можно обычный AusweisApp2
Ну да, я это и имел ввиду. Пользуетесь им? Реально полезно? Написано, что с ним можно некоторые услуги электронно получить, а не идти в амты и не стоять в очередях с бумажками или для получения бумажек. Типа российских "Госуслуг".
Насколько вспоминается, только в нем были очень странные глюки, типа "высота" страницы 0.
А иногда надо было ставить отрицательную высоту... КАК на него плевались фронтендеры, страшно вспомнить. А ещё мастдай не был бы мастдаем если б и в эту миску не попытался бы нагадить. И JScript он вводить пытался, и свои html-тэги, которые только IE поддерживал.
Пользуетесь им? Реально полезно? Написано, что с ним можно некоторые услуги электронно получить
Я три года назад на форуме писал, сейчас наверное ещё больше услуг предлагают: https://foren.germany.ru/showmessage.pl?Number=37453107&Bo...
Я когда уезжал, купил себе за 11 тысяч рублей приборчик, позволяет пользоваться онлайн государственными услугами Германии. Очень удобно в КБА всё по машине в Фленсбурге, в БФА в Кёльне всё по бафёгу, в БМИ, в БФЙ, в ДРВ ренту посмотреть... итд итп больше 100 разных предложений и услуг, но это конечно только для граждан Германии, а для мигрантов возможно доступа нет.
Государственные услуги в России и Германии конечно не сравнить, в России и квартиру за пару минут купить продать можно через госуслуги, к поликлинике прикрепиться и к врачу термин сделать. Или когда был комендантский режим в прошлом году - я себе там пропуска заказывал.
Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.
Дальше про хрень. Каково жить в мире, где 99% будет генерироваться РЕШАЮЩИМ!! искуственным идиотом? 108 миллионов просмотров в сумме на канале! Такое за несколько тысяч долларов продать можно (было) даже в ру-сегменте. В англоязычном такой канал стоит в разы больше.
Текст и картинки собираются по кускам в инете или генерируются тем же ИИ-ботом (что по сути то же самое собирание), затем текст проговаривается компьютером, картинки выстраиваются в видеоряд, проговоренный текст накладывается на полученное слайдшоу, генерится текст для оформления ролика и всё заливается на канал. Текст в названии и в описании может быть разной степени упоротости, но главное, чтобы побольше всяких сенсаций и слов, привлекающих внимание. В идеале суперсенсации должны следовать непрерывно. Ну и эта хрень работает в автоматическом режиме, генеря таким образом по нескольку роликов в сутки, хотя не вижу препятствий увеличить производительность на пару порядков. Ограничивает, наверное, лишь то, что потреблять это должны реальные люди, а их такой поток информационного дерьма быстро утопит. Поэтому подогнали более-менее под возможности реального человека просматривать такой канал. Добавляется перевод каким-нибудь гугл-транслейтом - и вот уже готовые аналогичные каналы для всех языков. Комменты тоже иногда, похоже, боты пишут.
Гуглу вообще не похер, что его платформу уже давно заваливают каналами с полностью автоматически созданным контентом? Просто интересно, как он это монетизирует. Рекламодатели тоже боты? А деньги у них реальные?