>Очень соблазнительно решить, что наконец-то нашёлся способ ничего больше не менять в процессах. И пусть он успевает за решениями, которые мы принимаем. Это ж робот, а код теперь вообще ничего не стоит.
Тоже замечаю такое отношение. Если раньше процесс регулярно замыкался на перекапывании стюардессы с места на место, то с приходом ИИ перекапывать стюардессу можно в 10 раз быстрей, а значит и в процессе можно ничего не менять. Ведь "что-то менять" - это значит, что придётся лезть в напряжённые отношения с бизнесом и вообще, о чём-то думать. А ИИ-шечка как-будто предлагает возможность вкинуть сто баксов и сказать "просто работайте в 10 раз быстрее - технологии это позволяют".
Я с вашим комментарием одновременно и очень сильно согласен и очень сильно не согласен.
Брал я одного такого тимлида, очень скоро стало ясно, что он пришёл сюда отбывать номер. Через 5 недель мы с ним расстались, не прошло даже половины испытательного срока. Так что баланс, всё-таки, нужно соблюдать.
А что до противоположности интересов работника и бизнеса - то всё это так, как дедушка Маркс ещё писал. И задача бизнеса организовать условия работы так, чтобы работнику было интересно выкладываться. Ведь это не такая уж и редкость, когда человеку нравится решать IT-задачи. Но для того, чтобы этот интерес у работника был и развивался, надо чтобы вся вертикаль управления была пропитана соответствующей культурой. А так, да, начиная с самых нижних звеньев управленческого звена - маразм, лень, некомпетентность, задвигание неудобных. И только последний линейщик должен думать "интересами бизнеса", а не только таски в Клод совать.
>Тест для понедельника. Возьмите любой регулярный отчёт программы и назовите решение, принятое по нему за последний месяц. Не назвали – вычёркивайте отчёт.
Узнаю родной завод... В том смысле, что решения не принимают, но отчёты не вычёркивают.
То, что делает эта библиотека - это совсем не "просто", ту же проблему cache stampede она решает из коробки плюс много разных других ништяков есть, для которых тысячи программистов по всему свету написали тысячи велосипедов.
Половину вашей боли библиотека решает: не нужно всякий раз делать round-trip до редиса, не нужно выкачивать громадную строку, не нужно сериализовать эту строку в модель. Остаётся только вторая половина проблема - сериализация этой модели в ответ HTTP. Насколько это в действительности проблема зависит от частоты запросов и размера хранимых данных. Допустим, что в вашем сценарии использования это действительно проблема. Но утверждать на этом основании, что "redis в принципе не слишком полезен для кэширования" - это слишком смелое обобщение.
Основная проблема неиспользования фич конкретной БД в том, что ради потенциального перехода на другую БД вы отказываете себе в использовании остро заточенных ножей конкретной БД. Есть, конечно, продукты, где совместимость с различными БД - это необходимая, а потому изначально заложенная возможность. Но и эта ситуация не обязывает отказываться от остро заточенных ножей и ограничиваться ванильным SQL, если правильно реализовать паттерн репозиторий.
У вас, всё-таки, ошибка в методе лечения. >Лечение: generic-ограничение where T : struct, IShape вместо переменной интерфейса — JIT специализирует код по value-типу и вызывает метод без упаковки.
struct в ограничении параметра интерфейса совсем необязательно указывать. Важно сделать аргументом метода не интерфейс, а generic-тип, на который наложено ограничение имплементировать нужный интерфейс. Тогда, как писал ещё Джеффри Рихтера, C# для reference-типов создаст одну общую имплементацию этого метода, а для каждого структурного типа сделает отдельную имплементацию. Эта отдельная имплементация будет знать конкретный тип параметра и не будет боксинга.
using System;
public interface IShape { double Area(); }
public struct Circle : IShape
{
public double R;
public double Area() => Math.PI * R * R;
}
public class C {
public double GetDoubleAreaWithBoxing() {
IShape s = new Circle { R = 2 };
return s.Area();
}
public double GetDoubleAreaWithoutBoxing() {
Circle circle = new Circle { R = 2 };
return GetShapeDoubleArea(circle);
}
public double GetShapeDoubleArea<T>(T shape) where T: IShape {
var area = shape.Area();
return area * 2;
}
}
Блог с комментом, конечно, учебный пример, но если отвечать кратко, то частая проблема с агрегатами именно в том, что для разных задач необходим различный набор данных.
Там, где данных немного, размером можно пренебречь. Когда полный агрегат становится достаточно большим, эта проблема появляется. И главная сложность в том, что границы таких агрегатов подвижны.
Если нет правил на добавление коммента, тогда коммент - агрегат. Если появляются правила, заданные постом, тогда агрегат уже пост. И эти правила могут меняться. Сначала вводится ограничение для ролевой модели (френд-не френд), потом добавляется ограничение на максимальное количество комментов к посту, потом для серебряных пользователей вводится расширенный лимит на добавление комментариев, а для золотых пользователей лимит и вовсе снимается. Грузить текст с картинками для определения правил всё равно не нужно.
На практике это часто приводит к протекающим моделям. В EF можно заинклюдить какие-то связи, а можно грузить сущность без них. В репу можно передать это флагами. На выходе будет "единая" модель, которая будет вести себя по разному в зависимости от того, каким образом был выгружен агрегат.
Таким образом, задача добавления комментария уже свою собственную модель доменной области потянет, под капотом которой, возможно, будет прятаться сущность EF. В общем, "агрегат" на практике получается более подвижная штука, чем это принято считать, и определяется во многом сценариями использования. Не сценарии от агрегатов пляшут, а агрегаты от сценариев.
Если у вас доменнная модель отделена от моделей EF, то изменения в доменной модели не трекаются EF. А ведь на этом "эффекте" (изменения "в памяти" плавно перетекут в БД) базируется уже логика доменного слоя.
Если вы попробуете добавить прослойку, которая будет делать маппинг из доменной модели в модель EF, то окажется, что это дело не такое уж и простое. Прямолинейный маппинг из одной сущности в другую будет работать, только если у вас вариант key-value хранилища. Маппинг, который "апдайтит" сущность написать не намного проще, чем собственный change-tracker.
В общем, от того, что под капотом репозитория на самом деле очень многое зависит на уровне бизнес-слоя. И от этой зависимости невозможно полностью абстрагироваться.
Про IQueryable, как протекающую абстракцию и про тестирование запросов in-memory +много. Сам на собесах такие вещи проверяю.
А вот про загрузуку всего поста для того, чтобы добавить один коммент (работа через агрегаты) - стоило бы отдельно поговорить.
Ну и в целом, для того чтобы паттерн "загрузли агрегат из репы -> внесли изменения в агрегат -> сохранили агрегат целиком" нужна либо ORM, либо key-value хранилище. И отсутствие вопросов с конкурентностью. А если на той стороне базёнка с процедурами, то уложиться в такой паттерн становится намного труднее. Так что инфраструктурные ограничения далеко не всегда DDD-паттернами устраняются.
>Очень соблазнительно решить, что наконец-то нашёлся способ ничего больше не менять в процессах. И пусть он успевает за решениями, которые мы принимаем. Это ж робот, а код теперь вообще ничего не стоит.
Тоже замечаю такое отношение. Если раньше процесс регулярно замыкался на перекапывании стюардессы с места на место, то с приходом ИИ перекапывать стюардессу можно в 10 раз быстрей, а значит и в процессе можно ничего не менять. Ведь "что-то менять" - это значит, что придётся лезть в напряжённые отношения с бизнесом и вообще, о чём-то думать. А ИИ-шечка как-будто предлагает возможность вкинуть сто баксов и сказать "просто работайте в 10 раз быстрее - технологии это позволяют".
Я с вашим комментарием одновременно и очень сильно согласен и очень сильно не согласен.
Брал я одного такого тимлида, очень скоро стало ясно, что он пришёл сюда отбывать номер. Через 5 недель мы с ним расстались, не прошло даже половины испытательного срока. Так что баланс, всё-таки, нужно соблюдать.
А что до противоположности интересов работника и бизнеса - то всё это так, как дедушка Маркс ещё писал. И задача бизнеса организовать условия работы так, чтобы работнику было интересно выкладываться. Ведь это не такая уж и редкость, когда человеку нравится решать IT-задачи. Но для того, чтобы этот интерес у работника был и развивался, надо чтобы вся вертикаль управления была пропитана соответствующей культурой. А так, да, начиная с самых нижних звеньев управленческого звена - маразм, лень, некомпетентность, задвигание неудобных. И только последний линейщик должен думать "интересами бизнеса", а не только таски в Клод совать.
Bug-driven-design. Да, есть такая штука.
>Тест для понедельника. Возьмите любой регулярный отчёт программы и назовите решение, принятое по нему за последний месяц. Не назвали – вычёркивайте отчёт.
Узнаю родной завод... В том смысле, что решения не принимают, но отчёты не вычёркивают.
Сколько реальной боли. И ведь DDD Эванса в первую очередь об этих вещах, а не о паттерне репозиторий.
А как вы удаление записи обнаружите? если не ошибаюсь, то описанный вами подход помогает обнаружить только добавленные и обновлённые записи.
Раз вам сложно найти такой сценарий, то не буду спорить.
То, что делает эта библиотека - это совсем не "просто", ту же проблему cache stampede она решает из коробки плюс много разных других ништяков есть, для которых тысячи программистов по всему свету написали тысячи велосипедов.
Половину вашей боли библиотека решает: не нужно всякий раз делать round-trip до редиса, не нужно выкачивать громадную строку, не нужно сериализовать эту строку в модель. Остаётся только вторая половина проблема - сериализация этой модели в ответ HTTP. Насколько это в действительности проблема зависит от частоты запросов и размера хранимых данных. Допустим, что в вашем сценарии использования это действительно проблема. Но утверждать на этом основании, что "redis в принципе не слишком полезен для кэширования" - это слишком смелое обобщение.
FusionCache?
У нас была плавающая ошибка, связанная с именем сети
Изначально код был написан так.
Тесты могли проходить, могли падать. Падали, когда два раннера работали одновременно.
Заработало, когда переписали вот так.
Или можно было просто WithName убрать.
Очень хорошая серия статей.
Не могу не плюсануть статью, где рифмуются слова automapper и ненависть.
Тот же путь и сам проходил и других к такому подталкивал.
Основная проблема неиспользования фич конкретной БД в том, что ради потенциального перехода на другую БД вы отказываете себе в использовании остро заточенных ножей конкретной БД. Есть, конечно, продукты, где совместимость с различными БД - это необходимая, а потому изначально заложенная возможность. Но и эта ситуация не обязывает отказываться от остро заточенных ножей и ограничиваться ванильным SQL, если правильно реализовать паттерн репозиторий.
У вас, всё-таки, ошибка в методе лечения.
>Лечение: generic-ограничение
where T : struct, IShapeвместо переменной интерфейса — JIT специализирует код по value-типу и вызывает метод без упаковки.struct в ограничении параметра интерфейса совсем необязательно указывать. Важно сделать аргументом метода не интерфейс, а generic-тип, на который наложено ограничение имплементировать нужный интерфейс. Тогда, как писал ещё Джеффри Рихтера, C# для reference-типов создаст одну общую имплементацию этого метода, а для каждого структурного типа сделает отдельную имплементацию. Эта отдельная имплементация будет знать конкретный тип параметра и не будет боксинга.
Вот ваш немного переделанный пример на sharplab. Ограничения struct нет, а боксинг лечится.
https://sharplab.io/#gist:a9fa36483d3aa22fb79b12b3704efac6
Блог с комментом, конечно, учебный пример, но если отвечать кратко, то частая проблема с агрегатами именно в том, что для разных задач необходим различный набор данных.
Там, где данных немного, размером можно пренебречь. Когда полный агрегат становится достаточно большим, эта проблема появляется. И главная сложность в том, что границы таких агрегатов подвижны.
Если нет правил на добавление коммента, тогда коммент - агрегат. Если появляются правила, заданные постом, тогда агрегат уже пост. И эти правила могут меняться. Сначала вводится ограничение для ролевой модели (френд-не френд), потом добавляется ограничение на максимальное количество комментов к посту, потом для серебряных пользователей вводится расширенный лимит на добавление комментариев, а для золотых пользователей лимит и вовсе снимается. Грузить текст с картинками для определения правил всё равно не нужно.
На практике это часто приводит к протекающим моделям. В EF можно заинклюдить какие-то связи, а можно грузить сущность без них. В репу можно передать это флагами. На выходе будет "единая" модель, которая будет вести себя по разному в зависимости от того, каким образом был выгружен агрегат.
Таким образом, задача добавления комментария уже свою собственную модель доменной области потянет, под капотом которой, возможно, будет прятаться сущность EF. В общем, "агрегат" на практике получается более подвижная штука, чем это принято считать, и определяется во многом сценариями использования. Не сценарии от агрегатов пляшут, а агрегаты от сценариев.
Если у вас доменнная модель отделена от моделей EF, то изменения в доменной модели не трекаются EF. А ведь на этом "эффекте" (изменения "в памяти" плавно перетекут в БД) базируется уже логика доменного слоя.
Если вы попробуете добавить прослойку, которая будет делать маппинг из доменной модели в модель EF, то окажется, что это дело не такое уж и простое. Прямолинейный маппинг из одной сущности в другую будет работать, только если у вас вариант key-value хранилища. Маппинг, который "апдайтит" сущность написать не намного проще, чем собственный change-tracker.
В общем, от того, что под капотом репозитория на самом деле очень многое зависит на уровне бизнес-слоя. И от этой зависимости невозможно полностью абстрагироваться.
>в книгах куча примеров
"- Так моему соседу 85, а он говорит, что с женщинами ещё ого-го.
- Вот и вы _говорите_" (c)
>Хотя возможно тут проблема что ОРМ через которую пишутся запросы не предоставляет возможности на такой запрос)
Т.е. у вас "архитектура" приложения возможностями ORM диктуется?
Про IQueryable, как протекающую абстракцию и про тестирование запросов in-memory +много. Сам на собесах такие вещи проверяю.
А вот про загрузуку всего поста для того, чтобы добавить один коммент (работа через агрегаты) - стоило бы отдельно поговорить.
Ну и в целом, для того чтобы паттерн "загрузли агрегат из репы -> внесли изменения в агрегат -> сохранили агрегат целиком" нужна либо ORM, либо key-value хранилище. И отсутствие вопросов с конкурентностью. А если на той стороне базёнка с процедурами, то уложиться в такой паттерн становится намного труднее. Так что инфраструктурные ограничения далеко не всегда DDD-паттернами устраняются.