Этот паттерн применяют даже не рассматривая других альтернатив
Как я понимаю, это не паттерн, это набор принципов, они могут применяться в различных паттернах.
А статья, конечно, крайне полезна: это лишний повод задуматься над тем, что знаешь. Вообще, как я помню из теории распознавания образов, механизмы обучения хорошо работают только тогда, когда помимо положительных обучающих примеров, есть и отрицательные.
Предположим, вы имеете два класса — A и B, которым требуются данные из репозитория. Причем, каждый из классов получает данные с использованием разных критериев поиска. Если вы вынесете логику получения данных за эти классы, то там вы будете вынуждены знать, как A и B формируются критерии поиска. А если классов не два, а десять? А если больше?
IoC-контейнер, в отличие от приведенного примера, не знает об особенностях тех классов, в которые он внедряет зависимости. Он лишь знает, что и куда ему надо внедрить (например, что если в конструкторе порождаемого класса есть параметр типа IServ1).
Вопрос к автору перевода: если вы добавили собственные трактовки принципов из SOLID (в оригинале их нет), то не стоит ли их пояснить? Например, Single Responsibility — это действительно «делай модули меньше»? Например, если модуль большой и несет более одной ответственности, то да «делай его меньше», а конкретнее — дроби. Но если модуль и так несет одну ответственность и является «high cohesive», то его дробление может привести к получению нескольких сильно связанных модулей (highly coupled), ответственность по которым размазана.
Мы получаем какие-то данные через зависимость? Передайте сами данные, но уберите ПолучательДанных.
На мой взгляд, следовало бы добавить сюда что-то вроде «Вынесите ПолучаетельДанных в какой-то код снаружи. В итоге вы получите кашу в этом коде, но не в рассматриваемом классе». Это было бы честно.
Мы же понимаем, что устранить все зависимости в системе не удастся. Классический пример — приложение, работающее с данными через Репозиторий. Зависимость обрабатывающего кода от репозитория все-равно останется. Вопрос только в том, где она в итоге будет: вы либо передадите ее туда, где нужно получить данные, либо вынесете в некий мега-менеджер, который сначала получит требуемые данные из репозитория, а потом вызовет класс, и так для каждого класса; в итоге вы просто получите что-то типа GodObject.
В статье полно спорных моментов, она как-то сильно упрощает решаемые разработчиками проблемы. Это видно и из комментариев к оригинальной статье, и по тому набору примитивных примеров, которые автор приводит в доказательство своих принципов в следующих своих постах.
Я бы очень советовал еще «молодым» разработчикам крайне критически взглянуть на этот материал. SOLID-давние и проверенные принципы ООП, направленные на борьбу со сложностью, и нужно очень хорошо понимать, где ими можно пренебречь, если это вообще требуется.
Это здорово, когда 007 осознает, что он им является! Бывает что человек явно из этой категории, но признать этого не хочет, поэтому к попыткам править свой код относится очень болезненно
Пара вопросов:
1. Каким образом определяются координаты для адреса? Ведь адреса берутся из ФИАС, как я понимаю.
2. На какой территории работают геокоординаты?
Хотелось бы понять, что заставляет Вас использовать EF, раз уже так много всего написано для ускорения? Это legacy code? Или есть еще какие-то объективные причины? Ведь в комментариях к первой статье уже предлагали linq2db, например.
А нельзя ли при детальной проработке упомянутые Вами моменты и добавить? Не это ли называется детальным проектированием? А представленная схема является лишь описанием высокоуровневой архитектуры. И она явно не единственная, о чем автор, к сожалению, явно не упомянул
Согласен, какие-то моменты относительно безопасности, например, могли бы появиться и на этой схеме. Особенно, если они архитектурно важны. Но если отметить на этой схеме все нюансы безопасности, то остальные элементы системы на этом фоне померкнут. А насколько я понимаю, высокоуровневое описание архитектуры предназначено для того, чтобы согласовать общее «архитектурное видение» системы со всеми участниками проекта, среди которых могут быть специалисты разного профиля.
Основная цель, для которой может потребоваться разработка LINQ-провайдера — это, на мой взгляд, обеспечение удобного средства написания запросов к таким источникам данных, к которым LINQ-провайдеров еще нет. Например, если мы захотим использовать PostgreSQL как документ-ориентированную NoSQL БД, сохраняя данные в JSON-поля, то для запросов мы будем вынуждены использовать имеющийся там синтаксис запросов. Наличие провайдера, подобного C#-драйверу для MongoDb, здесь было бы крайне полезным.
Что касается опыта, то его пока маловато, чтобы о нем написать. Хотя материал получился бы действительно интересным.
А статья, конечно, крайне полезна: это лишний повод задуматься над тем, что знаешь. Вообще, как я помню из теории распознавания образов, механизмы обучения хорошо работают только тогда, когда помимо положительных обучающих примеров, есть и отрицательные.
IoC-контейнер, в отличие от приведенного примера, не знает об особенностях тех классов, в которые он внедряет зависимости. Он лишь знает, что и куда ему надо внедрить (например, что если в конструкторе порождаемого класса есть параметр типа IServ1).
В оригинале — это вообще вторая часть поста.
На мой взгляд, следовало бы добавить сюда что-то вроде «Вынесите ПолучаетельДанных в какой-то код снаружи. В итоге вы получите кашу в этом коде, но не в рассматриваемом классе». Это было бы честно.
Мы же понимаем, что устранить все зависимости в системе не удастся. Классический пример — приложение, работающее с данными через Репозиторий. Зависимость обрабатывающего кода от репозитория все-равно останется. Вопрос только в том, где она в итоге будет: вы либо передадите ее туда, где нужно получить данные, либо вынесете в некий мега-менеджер, который сначала получит требуемые данные из репозитория, а потом вызовет класс, и так для каждого класса; в итоге вы просто получите что-то типа GodObject.
В статье полно спорных моментов, она как-то сильно упрощает решаемые разработчиками проблемы. Это видно и из комментариев к оригинальной статье, и по тому набору примитивных примеров, которые автор приводит в доказательство своих принципов в следующих своих постах.
Я бы очень советовал еще «молодым» разработчикам крайне критически взглянуть на этот материал. SOLID-давние и проверенные принципы ООП, направленные на борьбу со сложностью, и нужно очень хорошо понимать, где ими можно пренебречь, если это вообще требуется.
1. Каким образом определяются координаты для адреса? Ведь адреса берутся из ФИАС, как я понимаю.
2. На какой территории работают геокоординаты?
Согласен, какие-то моменты относительно безопасности, например, могли бы появиться и на этой схеме. Особенно, если они архитектурно важны. Но если отметить на этой схеме все нюансы безопасности, то остальные элементы системы на этом фоне померкнут. А насколько я понимаю, высокоуровневое описание архитектуры предназначено для того, чтобы согласовать общее «архитектурное видение» системы со всеми участниками проекта, среди которых могут быть специалисты разного профиля.
Что касается опыта, то его пока маловато, чтобы о нем написать. Хотя материал получился бы действительно интересным.