А как такая хрень вообще происходит?
Программист, надеющийся, что за 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 человека. И тянули, и развивали и для клиентов новые свистелки реализовывали. Так что помолчи уже, за умного сойдёшь.