• Scrum is dead
    0

    Надо взять на вооружение:)

  • Деревья выражений в enterprise-разработке
    0
    А эта штука тоже декомпилирует через GetIlAsByteArray?
  • Деревья выражений в enterprise-разработке
    0

    Спасибо за то что поправили. Я конечно имел в виду C#. В F# ещё и провайдеры типов и проблематика EF в нем не так актуальна.

  • Распараллеливание задач с зависимостями —  пример на .NET
    0

    Присоединяюсь к просьбе сообщить о начале продаж.

  • Директор по здравому смыслу: как перестать все контролировать и начать работать в команде
    0
    Нет, не получается. Тимлид — зам. менедежера по технической.
  • ThinkingHome.Migrator — версионная миграция схемы базы данных на платформе .NET Core
    0

    При условии, что вы пишете seed’в есть такое «костыль»: делаете батник с миграцией init, пишете код, удаляете миграции, вызываете init и migrate. В каждый момент у вас одна миграция. Менее изящно, но на этапе прототипирования бывает удобно. Если pk надо заменить, например.

  • Доступ к данным в многопользовательских приложениях
    +1
    В своей практике я не припомню случаев необходимости в таких пользователях.

    Техподдержка Azure или YouTrack, например, чудесным образом имеет доступ к моим данным в облаке и помогает решать проблемы, когда что-то не работает;)
  • Доступ к данным в многопользовательских приложениях
    0
    Вообще, ограничения доступа которые вы описали в статье, это больше похоже на бизнесовые правила и им место скорее в спецификациях, а не на глобальном уровне. Применяя их на глобальном уровне вы можете столкнутся с ситуацией когда вам нужно получить данные не применяя эти правила.
    Да и тогда нужно будет обращаться к другому контексту, который возвращает не «отфильтрованный» IQueryable. Кроме того этот случай решается «супер-пользователем», который видит все и может логиниться от имени кого угодно. Де-факто такой пользователь почти всегда появляется:)

    На самом деле ничего не мешает использовать спецификации внутри таких фильтров. Я просто не стал усложнять код в примере.
    На мой взгляд, проще ориентироваться в наборе спецификаций имеющих четкое название и четкое назначение чем в куче условий в Where. Тем более что со спецификациями вы уже имели дело.
    Да, но если эти данные вообще не предназначены для данного пользователя зачем ему вообще иметь возможность их видеть? Неявность имеет не только плохую, но и хорошую сторону. В некоторых случаях хорошо, что прикладной разработчик не заботится о доступе. Снижает нагрузку на мозг.

    Кстати говоря, как ваше впечатление от них спустя год?
    Короткий ответ — отлично. Если хотите длинный ответ, то <a href=«www.youtube.com/watch?v=DD3w66Ff8Ms&t=948s.
  • Доступ к данным в многопользовательских приложениях
    –1
    Да, можно решать спецификациями, но это не гарантирует, что разработчик не забудет дописать queryable.Where(spec).
  • Доступ к данным в многопользовательских приложениях
    0
    Использование разных интерфейсов эту проблему решает на 100%: используете DbSet напрямую — фильтров нет. Используете абстракцию — фильтры есть. Если используете глобальные фильтры DbContext.Set<T>() — с фильтрами, DbContext.Set<T>().IgnoreQueryFilters() — без.
  • Доступ к данным в многопользовательских приложениях
    0

    Что вы имеете в виду, когда говорите «оттрекать»?

  • Доступ к данным в многопользовательских приложениях
    0

    Если ну очень хочется, то регистрацию можно вынести в отдельную сборку и подключить к хосту уже ее. Бывает полезно, если хостов много. В общем случае вы правы.

  • Доступ к данным в многопользовательских приложениях
    0
    Предложенный вами подход имеет преимущество: он более явный. С другой стороны вам придется теперь везде писать Context.GetPermittedUsers(). Как проконтролировать, что другой разработчик по ошибке не вызовет Context.Users? В варианте с дополнительным интерфейсом можно вообще не подключать EF к web-проекту и работать только через слой бизнес-логики. Еще на extension'ы не повесить декораторы.
  • JavaScript. Работаем с исключениями и данными в конструкциях async/await без блоков try-catch
    +1

    Обратите внимание на вот такой подход: https://m.habr.com/post/339606/. Все try/catch уйдут, но обработка ошибок останется

  • Чем бизнесу и пользователям грозит борьба РКН и Telegram? Мнения экспертов
    +1

    Например то, что у меня на конкретной машине не было локального кеша и я минут 5 соображал почему у меня Rider пакеты не обновляет

  • О декораторах, сквозной функциональности, CQRS и слоеной архитектуре
    0
    Думаю, доменные события для такого логирования подойдут лучше декораторов.
  • О декораторах, сквозной функциональности, CQRS и слоеной архитектуре
    0

    Добавьте дополнительное логирование в необходимых ветках. Можно явно с помощью императивного кода или с помощью декораторов для декораторов. Это как удобнее. Цель статьи — показать как можно очистить доменную логику от инфраструктурного кода. Взаимодействие инфраструктуры с инфраструктурой — другой вопрос.

  • О декораторах, сквозной функциональности, CQRS и слоеной архитектуре
    0

    Спасибо большое за комментарий. Вы поняли все верно. Я теперь знаю, что донёс идею внятно:)

  • О декораторах, сквозной функциональности, CQRS и слоеной архитектуре
    0
  • Паттерны внедрения зависимостей. Часть 1
    0
    Как гарантировать, что вызов DoSomething из вашего примера произойдет после того как Dependency будет установлен?
  • Паттерны внедрения зависимостей. Часть 1
    0
    «Необязательные зависимости» довольно часто свидетельствуют о нарушении SRP и приводят к NRE. Так что лучше без них.
  • REST API Best Practices
    0

    Или 422, например если валидация не прошла.

  • Почему не работают Уставы и Планы управления проектом?
    0
    Де-факто все это разбивается о нашу судебную систему. Довольно часто дороже судиться, чем расстаться с клиентом. Кроме того, не всегда судебное решение легко исполнить.
  • Опыт разработки некоммерческого проекта силами джуниоров
    0

    Может потому что этих людей за деньги не спешат брать и они хотят набраться опыта, чтобы брали?

  • Если у вас нет собаки…
    +2
    А писали бы на .NET взяли бы готовый SpecFlow :)
  • Карго-культ вокруг и внутри нас: IT HR и маркетинг
    0
    Тут: cargo-cult.club? Видео трансляции появится вместо регистрации?
  • Карго-культ вокруг и внутри нас: IT HR и маркетинг
    0
    А трансляция будет?
  • Вопросы для собеседования бэкенд-разработчика
    +1

    Я на большинство вопросов «хотите обсудить эту тему» ответил «нет»:) Видимо, меня не возьмут.

  • Кто такой программист?
    –1

    Вы не один такой. Мне 29, я тоже окончил физ-мат школу и виду как снижается качество образования. Готовят в основном «обслуживающий персонал». Может это и неплохо, но все чаще ощущаю себя героем романа Олдоса Хаксли.

  • CQRS. Факты и заблуждения
    0
    Кстати, не хотите подлелиться опытом в DDD в комментариях здесь? Я как раз затронул тему «прикладного» DDD в рамках ООП-парадигмы.
  • Domain Driven Design на практике
    0
    cartCalculator.Calculate(cart), кэп!:) Калькулятор считает ценую корзины, потому что скидки могут применять как позиции заказа, так и заказу в целом. Бывает «3 по цене 2», «купи на 3000 рублей и получи в подарок шнурки для галошь» и просто накопительные скидки для постоянных клиентов.
  • CQRS. Факты и заблуждения
    +1
    F# в вопросе типов сильнее C#. Например, union'а часто не хватает для моделирования, приходится multiple dispatch городить. Опять же какое ООП имеется в виду? То, что в C++ или в SmallTalk?
  • Domain Driven Design на практике
    0
    На одном из проектов есть такая задача. У нас отдельно Product.BasePrice и есть CartCalculator. Внутри калькулятора — еще другие зависимости, которые расчитывают цену в зависимости от лицензии, роялти, накопительной скидки и других бизнес-правил.
  • Domain Driven Design на практике
    0
    Можете раскрыть свой вопрос более подробно?
  • Domain Driven Design на практике
    0
    Спасибо за вопросы.
    Обоснуйте пожалуйста, почему метод Accept принадлежит сущности Company. Ведь аккредитация выдается Ведомством. А то получается что компания сама себя куда хочешь может аккредетировать… Ну или как минимум в этот метод должен передаваться Policy ведомства или экземпляр объекта Аккредитация, с данными кто выдал и почему.

    Именно в данном приложении ведомство было одно, а аккредитация проходила автоматическом режиме при закрытии квартала при соблюдении определенных условий. Сущность в проекте называется по другому и там довольно увесистый агрегат. Возможно более естественно смотрелись бы названия методов BecomeAccepted и BecomeDeclined, чтобы субъект и объект действия не путались.

    Почему метод DangerouslyChangeInnAndKpp вообще содержит в себе эту приставку? Если предметной области это нормальное явление — это бессмысленно. Может стоило тогда ввести другую сущность?

    Смена ИНН и КПП — это перерегистрация. Т.е. в реальном мире нельзя просто так взять и сменить. Однако, предполагалось, что в подаваемых сведениях могут быть ошибки и к системе были предъявлены требования дать возможность эти ошибки исправлять.
    Название DangerouslyChangeInnAndKpp навеяно React'ом. Видимо, зря я удалил аннотации, в которых эта логика объяснялась.

    Я не знаком с .Net вообще, но вы упоминаете «луковую» и «чистую» архитектуры, а потом в домене используете public class Specs. Разве это не кусок вашего фреймворка только что просочился в домен? Т.о. вы нарушаете направление связей.

    В .NET на уровне платформы встроены «деревья выражений» (Expression Trees). Например:
    Expression<Func<Company, bool>> acceptedSpec = 
         x => x.State = CompanyState.Accepted;
    

    Expression<Func<Company, bool>> — довольно многословная конструкция. Spec<T> — более читаемая и сразу специализирована для сигнатуры T -> bool. Плюс добавлена перегрузка операторов && и ||. Спецификация по определению представляет правила бизнес-логики, т.е. является частью домена.

    Необязательно создавать спецификации внутри класса сущности, можно положить их рядом. Мне просто удобно использовать такой синтаксис: Company.Specs.Accepted. Все бизнес-правила фильтрации агрегата Company под рукой и intellisense поможет их найти. Можно использовать и другие правила, например отдельный статический класс. Тогда будет так: CompanySpecs.Accepted.
  • Domain Driven Design на практике
    0
    Промахнулся и ответил вам ниже отдельным комментарием.
  • Domain Driven Design на практике
    0
    Непонятно только только, почему при использовании DDD нельзя описывать бизнес логику в сервисах

    Почему же нельзя? Сервисам посвящен целый параграф. Другой вопрос, что есть смысл хранить не всю логику. Обратите внимание на метод Decline. Он четко показывает: чтобы отклонить заявку необходимо добавить непустой комментарий с пояснением, почему компания не может быть аккредитована. Представьте, у нас в домене три бизнес-сценария, где мы должны отклонять аккредитацию. Где гарантия, что все три метода будет реализовывать один разработчик? Даже если так, он может забыть правило про обязательный комментарий. В варианте с отдельным методом это невозможно.

    Кроме того в реальном приложении при отклонении необходимо было хранить историю заявок, в том числе с указанием менеджера, работающего с юр.лицом. При переходе из одного статуса в другое необходимо было менять 2-3 разных поля по определенным правилам. Объектная модель с поведением здорово помогает с пониманием «что здесь происходит и почему».

    Более подробно этот вопрос раскрывает Дино Эспозито. Ближе к концу доклада он приводит следующий пример. Допустим, в поддержку приходит баг. Пользователь объясняет, что он совершил некоторое действие, но ему не были начислены бонусные балы (или типа того). Если в коде программист видит «репозитории» и изменение каких-то свойств ему потребуется приложить дополнительные усилия, чтобы интерпретировать слова пользователя и сопоставить с кодом. А если он видит в коде нечто вроде:
    if(user.IsVip)
    {
       user.AddBonus(100);
    }
    

    Он может сразу уточнить статус пользователя. Может быть, про бонусные баллы он услышал от друга, а про VIP-статус позабыл. Может быть у нас баг и пользователю не был присвоен VIP-статус, хотя должен был. В любом случае, диалог получится куда более предметным.
  • Domain Driven Design на практике
    0
    Спасибо за комментарий. Ошибся при редактировании кода. ToList там вообще не скомпилируется, потому что ByInnAndKpp выполняет FirstOrDefault. Добавил пример метода ByInn и отредактировал статью.
  • CQRS. Факты и заблуждения
    0
    Тогда я не понимаю, чего вы хотите. Все возможные варианты не устраивают:)
  • CQRS. Факты и заблуждения
    0
    Но сути это не меняет. Нужно бросить исключение чтоб прекратить выполнение и поднять сообщение(я) об ошибке наверх в контроллер. Я не в восторге от такого подхода.

    В моем примере используется возвращаемый тип Result, а не исключения. Подробно подход описан здесь.