.Net Framework позволяет создавать сборки из нескольких файлов. Инструментом является утилита assembly linker. Это альтернатива «ручной» архивации. Конечно, трудно сказать что лучше конкретно в вашем случае.
Неа. IDependencyResolver (за компанию с еще некоторыми классами) — это точка расширения, позволяющая использовать в WebAPI тот DI-контейнер, который нужен программисту. Совершенно штатная.
Что собственно я и написал. И нужен он потому что оба фреймворка завязаны на использование конструкторов. Вы или читать не умеете или просто некомпетентны.
DI Container — «создает граф объектов», «зависимости декларируются в конструкторе (обычно)».
OData WebAPI «содает контроллеры для обработки запросов», «наследуется базовый контроллер, который может дать ограничение на конструктор».
Соотвествено реализация IDependencyResolver и является адаптером, который позволяет интегрировать оба фреймворка.
Суть проблемы в том, что вам нужно подружить два фреймворка, которые диктуют дизайн — DI Container и OData WebApi. Так как оба фреймворка хотят «контроллировать» конструктор, нужен какой-то "костыльадаптер" для того чтобы их подружить.
Вы описали типичную проблему интеграции и к самим принципам DI она не имеет отношения.
Давайте рассмотрим ситуацию: «Я отлаживал код, написанный сотрудником, который всё бросил, не дописал и ушел домой.» Тут есть несколько вариантов.
1. Ушел домой в 14:00. Такого сотрудника можно просто уволить за прогул.
2. Не успел все сделать в срок из-за недостатка компетентности. Вопрос, кто поручил эту работу такому сотруднику?
3. Не успел все сделать из-за внешних причин — проблемы с планированием, требованиями и т.п. Вопрос, почему сотрудник должен брать на себя чужие риски?
Если автор не смог ответить для себя на эти вопросы, то менеджер из него некудышний.
Вообще статья печальная и показывает, насколько стрессовый менеджмент пустил у нас корни. Чтобы использовать потенциал сотрудников на максимум, нужно в первую очередь устранить все преграды, которые мешают им работать а не бегать и кричать «А кто это сделал»?
В прошлом году я собеседовал настолько старательного, усердного и профессионального в своей работе программиста, что он создал полный Javadoc с комментариями к своему коду прежде, чем счел задачу выполненной. Он даже написал полностью автоматизированные unit-тесты и проверил процент покрытия ими кода. Когда я вернулся в комнату по истечении 2 часов, он неистово стучал по клавиатуре, и я было решил, что у него проблемы с выполнением задания, но на самом деле он как раз добавлял HTML-форматирование в свой Javadoc
Пример задания, которое можно понять, выполнить, покрыть тестами, сгенерировать документацию и высчитать покрытие за 2 часа?
Судя по наличию по крайней мере нескольких юнит-тестов и не 100% покрытия задача сама по себе не маленькая. Больше похоже на кулстори.
Вообще в программировании хороший, надежный и качественный код в незнакомом контексте быстро не пишется. Это аксиома.
Относительно «быстро» писать качественный код можно лишь хорошо владея всем аспектами проекта — бизнес, дизайн, технологии, нефункциональные требования, принятые конвенции, процесс и тп.
А оценивать программиста по скорости работы — тут скорее к «индусам» — тяп-ляп и готово — закрыл требования а дальше хоть трава не расти.
Найти литературу по всем вообще будет трудно, но я бы рекомендовал начать с книг, которые развивают в плане объектно-ориентированного дизайна:
Dependency Injection In .Net by Mark Seeman.
The Art Of Unit-Testing by Roy Osherove.
после можно читануть:
Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans (там много букв и напсано в духе научного эссе)
Design Patterns by GoF
По микросервисам Фаулер, также хороши его паттерны рефакторинга. По CQRS Udi Dahan.
Издания Microsoft по архитектуре рекомендую читать людям с уже устоявшимися взглядами.
Статья опоздала лет на 10, мир меняется и не стоит на месте, где современные вопросы и ответы?
Зачем выделять Data Acesss из инфраструктуры?
Где Application слой, который является клеем для инфраструктуры и бизнес логики?
Где упрощение количества связей путем агрегатов?
Где разделение на комманды и запросы (CQ, CQRS)?
Где Microservices?
Где реализация cross cutting-concerns, аспектов?
Где средства loosely coupled messaging, благодаря которому отдельные слои могут общаться между собой?
Как бороться с утечками функциональности в слои, которым они не принадлежат?
Как сделать приложение масштабируемым изначально?
Где наша любимая транзакционность в распределенной системе?
Статья неструктурна, сначала идет логический дизайн, потом объектно-ориентированный дизайн в виде SOLID, потом инфраструктура в виде DI, потом loose coupling, c которого было бы неплохо начать. В итоге надергано с миру по нитке. Пригодится студенту написать CRUD в виде customers/orders.
Часть ваших вопросов может быть отвечена в этом топике.
Как правило разработчик решает, исходя из какой ревизии создавать новый коммит, основываясь на том, в какие ветки должен попасть его код. Допустим багфикс релиза он фиксит в релизной ветке и переносит изменения во все ветки, где этот багфикс актуален.
Это все сугубо индивидуально для процесса, проекта и задачи, универсального ответа нет.
Проще говоря, бранчи жизнеспособны только тогда, когда у вас есть административный ресурс, заставляющий всех мержиться не реже раза в день.
Это сложный вопрос, но мне кажется что примеры разработки open-source проектов говорят нам об обратном. Можно далеко не ходить и рассмотреть то, как появился Git и какая модель используется для разработки Linux.
К сожалению реальный мир накладывает ограничения и не все можно успеть сделать за день) Если бы был телепорт не нужны были бы автомобили. А по поводу зависимости от рефакторинга — спасибо, я думаю можно отнести это как частный случай архитектурной зависимости.
1. Никто не запрещает синхронизировать ветки с mainline, как только в mainline попадают законченные изменения. Перед мержем с mainline никто не запрещает сначала синхронизироваться с оной и прогнать тесты.
2. Любой существенный функционал или рефакторинг не выполнишь за день, частые коммиты таких работ в mainline дестабилизирует его на срок до окончания разработки этого функционала или окончания рефакторинга. Откат последнего коммита в середине работы может привести к тому, что в mainline будет полуготовый функционал, что негативно сказывается на стабильности mainline.
3. Никто не запрещает интегрироваться между ветками, чтобы не накапливался эффект отложенной интеграции, если этот эффект способен вызвать big bang merge.
4. Использование веток позволяет осуществлять параллельную разработку, что позволяет, заплатив определенную цену, обойти ограничения реального мира — например одновременную пост-релиз поддержку и добавление новых фич.
5. Еще раз повторю что обмениваться лучше законченными изменениями но при этом коммитить часто — при работе mainline-only это проблематично.
Что собственно я и написал. И нужен он потому что оба фреймворка завязаны на использование конструкторов. Вы или читать не умеете или просто некомпетентны.
OData WebAPI «содает контроллеры для обработки запросов», «наследуется базовый контроллер, который может дать ограничение на конструктор».
Соотвествено реализация IDependencyResolver и является адаптером, который позволяет интегрировать оба фреймворка.
костыльадаптер" для того чтобы их подружить.Вы описали типичную проблему интеграции и к самим принципам DI она не имеет отношения.
1. Ушел домой в 14:00. Такого сотрудника можно просто уволить за прогул.
2. Не успел все сделать в срок из-за недостатка компетентности. Вопрос, кто поручил эту работу такому сотруднику?
3. Не успел все сделать из-за внешних причин — проблемы с планированием, требованиями и т.п. Вопрос, почему сотрудник должен брать на себя чужие риски?
Если автор не смог ответить для себя на эти вопросы, то менеджер из него некудышний.
Вообще статья печальная и показывает, насколько стрессовый менеджмент пустил у нас корни. Чтобы использовать потенциал сотрудников на максимум, нужно в первую очередь устранить все преграды, которые мешают им работать а не бегать и кричать «А кто это сделал»?
Я бы сказал что все имеет свою цену, в том числе и экономия.
Пример задания, которое можно понять, выполнить, покрыть тестами, сгенерировать документацию и высчитать покрытие за 2 часа?
Судя по наличию по крайней мере нескольких юнит-тестов и не 100% покрытия задача сама по себе не маленькая. Больше похоже на кулстори.
Относительно «быстро» писать качественный код можно лишь хорошо владея всем аспектами проекта — бизнес, дизайн, технологии, нефункциональные требования, принятые конвенции, процесс и тп.
А оценивать программиста по скорости работы — тут скорее к «индусам» — тяп-ляп и готово — закрыл требования а дальше хоть трава не расти.
Скорость программирования в реальной жизни и в кино
Dependency Injection In .Net by Mark Seeman.
The Art Of Unit-Testing by Roy Osherove.
после можно читануть:
Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans (там много букв и напсано в духе научного эссе)
Design Patterns by GoF
По микросервисам Фаулер, также хороши его паттерны рефакторинга. По CQRS Udi Dahan.
Издания Microsoft по архитектуре рекомендую читать людям с уже устоявшимися взглядами.
Зачем выделять Data Acesss из инфраструктуры?
Где Application слой, который является клеем для инфраструктуры и бизнес логики?
Где упрощение количества связей путем агрегатов?
Где разделение на комманды и запросы (CQ, CQRS)?
Где Microservices?
Где реализация cross cutting-concerns, аспектов?
Где средства loosely coupled messaging, благодаря которому отдельные слои могут общаться между собой?
Как бороться с утечками функциональности в слои, которым они не принадлежат?
Как сделать приложение масштабируемым изначально?
Где наша любимая транзакционность в распределенной системе?
Статья неструктурна, сначала идет логический дизайн, потом объектно-ориентированный дизайн в виде SOLID, потом инфраструктура в виде DI, потом loose coupling, c которого было бы неплохо начать. В итоге надергано с миру по нитке. Пригодится студенту написать CRUD в виде customers/orders.
Как правило разработчик решает, исходя из какой ревизии создавать новый коммит, основываясь на том, в какие ветки должен попасть его код. Допустим багфикс релиза он фиксит в релизной ветке и переносит изменения во все ветки, где этот багфикс актуален.
Это все сугубо индивидуально для процесса, проекта и задачи, универсального ответа нет.
Это сложный вопрос, но мне кажется что примеры разработки open-source проектов говорят нам об обратном. Можно далеко не ходить и рассмотреть то, как появился Git и какая модель используется для разработки Linux.
2. Любой существенный функционал или рефакторинг не выполнишь за день, частые коммиты таких работ в mainline дестабилизирует его на срок до окончания разработки этого функционала или окончания рефакторинга. Откат последнего коммита в середине работы может привести к тому, что в mainline будет полуготовый функционал, что негативно сказывается на стабильности mainline.
3. Никто не запрещает интегрироваться между ветками, чтобы не накапливался эффект отложенной интеграции, если этот эффект способен вызвать big bang merge.
4. Использование веток позволяет осуществлять параллельную разработку, что позволяет, заплатив определенную цену, обойти ограничения реального мира — например одновременную пост-релиз поддержку и добавление новых фич.
5. Еще раз повторю что обмениваться лучше законченными изменениями но при этом коммитить часто — при работе mainline-only это проблематично.