• JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    +2
    Я имел ввиду, что не стоит проверять то, что не может произойти и предполагать как может измениться система в своих попытках перестраховаться.
    В большинстве случаев в итоге выходит просто куча никому не нужного кода, который все равно нужно поддерживать.
  • JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    0
    Да. Но, в теории, они могут появится при внесении изменений.

    Лучший код — не написанный.
  • Зачем солить HTTP-коллбэки
    +1
  • Разбор PHP-задач Badoo и новый тест. Как получить оффер в Лондон в феврале
    +1
    Поддерживаю
  • Еще немного о валидации в ASP.NET
    +1
    Я не использую эксепшены для control flow.

    Есть условно хепи-пас. И есть разные ситуации, когда действие совершить невозможно.
    Простой пример ошибка при попытке купить товаров больше, чем доступно на складе. Бизнес-слой отреагирует эксепшеном, так как это недопустимая операция. Бизнес слой не знает словит кто его или не словит. Его задача либо оформить заказ на товары, либо выбросить ошибку.
    А вот UI слой как раз и занимается тем, что формирует представление для юзера.
    Да, теоретически можно было бы всегда возвращать FailedResult, но никто не гарантирует, что результат будет проверен.
  • Еще немного о валидации в ASP.NET
    0
    Это исключения. CommandHandler всегда возвращает успешный результат.
  • Еще немного о валидации в ASP.NET
    +1
    Не совсем. У меня есть ряд общих ошибок: UserNotFound / ProductNotFound, которые летят из репы. OrderCantBePaid, ProductOutOfStock, которые могут летать из определенных сервисов. Но эти ошибки не вылетают в контроллер, потому что отсутсвие юзера может быть как 404, так и 422 в разных запросах. Так что все потенциальные ошибки ловятся хендлером команды и в случае возникновения заворачиваются в новую. Например при попытке поместить в корзину несуществующий товар или в корзину несуществующего юзера вылетит в контроллер AddToBasketError, которая в свою очередь уже сконвертится в код 422 и боди типа такого
    {
        "message": "Product can't be added to basket.",
        "logref": "...",
        "_embedded": {
            "errors": [{
                    "message": "User #123 doesn't exist.",
            }]
        }
    }
    
  • Еще немного о валидации в ASP.NET
    0
    Вам не кажется странным пытаться совершить бизнес действие с заведомо неверными входными данными?
    Это валидация разного уровня, и ошибки разного типа.
    В ответ на кривой запрос веб приложение должно отдать «Bad request», а при попытке совершить некорректное бизнес действие — «Conflict», «Not found» или другой подходящий ответ в зависимости от ситуации.
  • Еще немного о валидации в ASP.NET
    0
    1. CQRS не обязан быть асинхронным
    2. Если вам не нужен CQRS — не используйте, но бизнес логике все равно место в бизнес-слое, а не в контроллерах

    зы. Я не повторял аргументы о транзакциях вполне особенно, хотя да, стоило добавить ссылку на комментатора ниже.
  • Еще немного о валидации в ASP.NET
    0
    Тоесть вы пишите без тестов?
    В моем случае для БЛ нужно писать юнит тесты, которые пишутся быстрей и проще, чем end-to-end тесты. Их может быть больше, но все они небольшие и очень быстро гонятся на CI. TDD становится не обузой (опять тесты писать), а инструментом. Хотите верьте, хотите нет, но 90% задач я делаю не запуская написанный код вручную, только гоняя тесты.

    Интерфейсы нужны на границах слоев в основном. Да, они нужны для стратегий, визиторов и других сервисов, имеющих множественные имплементации, но там их можно выделить уже тогда, когда они реально станут нужны. И это будет рефакторинг в бизнес-логике, который никак не отразится на слое UI. Там по прежнему будет commandHandler.execute(command);

    Валидацию вы и так делаете. Но в моем случае валидация типов\форматов будет в конструкторе команды, а валидация бизнес-логики в хендлере этой команды, а не скопом в контроллере.
  • Еще немного о валидации в ASP.NET
    0
    Cколько «столько»? Кода даже по сути будет столько же, только размещаться будет на разных слоях.
  • Еще немного о валидации в ASP.NET
    0
    Я о том, что БЛ не должна зависеть от фреймворка или от ОРМ или любой другой либы.
    Ну условно, завтра в секьюрити компоненте фреймворка найдут критическую уязвимость или упретесь в производительность EF и нужно будет переписать на чистый sql. Вам придется во всех местах, где опираетесь на сторонние классы — переписывать.
    Потому что у вас зависимость от реализации, а не интерфейса.

    Я не призываю отказаться от фреймворка или ОРМ. Я призываю соблюдать границы между слоями.
  • Еще немного о валидации в ASP.NET
    0
    Зачем ждать критическую массу?
    Реализовать хотя бы Command не так сложно.
    Это сразу дает ряд преимуществ:
    1. Можно покрыть бизнес-логику юнит тестами, что гораздо проще и быстрей чем тесты через хттп запросы.
    2. Разработка становиться ориентированной на use cases. Обработка каждого кейса строго изолирована. Беглого взгляда на список команд достаточно, что бы понять на что способна система.
    3. Вот тут можно применить байндинг реквеста на объект команды, в котором и будет зашита валидация. Что все идентификаторы и данные на месте, что они в правильном формате. А в контроллерах будет минимум логики:
    commandHandler.execute(command);
    

    4. Вы практически за бесплатно закладываете фундамент для масштабирования в будущем. Достаточно легко можно будет перенести денормализированные данные в хранилище, оптимизированное под чтение и внедрить CQRS.
  • Еще немного о валидации в ASP.NET
    0
    Не прибивает. В популярных ORM на .NET достаточно давно используются POCO. Т.е. — сущности — это просто классы. Они не зависят от фреймворка.


    Я о байндинге параметров контролера, когда идентификаторы в хттп-запросе автоматически превращаются в сущности из слоя хранения данных.

    1. UI-слою незачем знать о хранении совсем.
    2. И, тут я не уверен, этот байндинг часть фреймворка или часть языка? Если часть фреймворка, то не будет работать с другим без перепиливания.

  • Еще немного о валидации в ASP.NET
    0
    Не совсем. Проверка существования перед перемещением — это правило бизнес-логики и должно проверяться в доменном сервисе, а не в контроллере. Вы прыгаете с UI сразу в Persistence слой, минуя бизнес логику. Собственно последний шаг к ТолстымУродливымКонтроллерам — прямо здесь же в контролере написать что-то типа

    product.Category.removeProduct(product);
    
    category.addProduct(product);
    
  • Еще немного о валидации в ASP.NET
    +2
    Просто нужно писать бизнес-логику не завязанную ни на фреймворк, ни на орм.
    Пример с хранилищем. В бизнес слое есть IProductRepository. В слое инфраструктуры лежит DbProductRepository и InMemoryProductRepository. Все сервисы в бизнес-слое завязаны на IProductRepository, а уж какую реализацию им передашь — дело десятое. Более того, можно всю бизнес-логику написать до того как вообще определишься с хранилищем, фреймворком и т.д.
  • Еще немного о валидации в ASP.NET
    0
    Я может чего-то не понимаю в этих ваших шарпах, но для меня этот подход попахивает нехорошим.

    Тут смешаны слои. Слой UI, слой бизнес-логики и слой хранения данных. На уровне контроллера нельз провалидировать ничего, кроме формата запроса. Наличие всех обязательных полей, соответствие типам и форматам (положительные целые/UUID-строки для идентификаторов, валидный email, etc).
    Валидация наличия категорий и товаров — это правило бизнес-логики и место ему в бизнес-слое.

    Биндинг моделей к параметрам контролера прибивает вас гвоздями к фреймворку. Возможно в мире шарпа нет альтернатив, но на пыхе мне приходилось интегрировать магазины с разными фреймворками и даже с системами без фреймворков (а давайте добавим страничку, где будем продавать товары онлайн… на бложик, накиданный на коленке 10 лет назад, ага...). Если бизнес логика не завязана на конкретный фреймворк — это сделать несложно.

    зы. Ну и от dbContext коробит. А что если приложение должно уметь работать вообще без бд? Или использовать редис как хранилище? Получается мы снова жестко прибиты к EF.
  • [Перевод] Анемичная модель предметной области — не анти-шаблон, а архитектура по принципам SOLID
    0
    Недавно добавили в свое приложение интерфейс ITimeProviderService =)
    Действительно полезная штука на самом деле
  • REST — это новый SOAP
    +2
    Пользователи всегда уходят с ресурса, если он работает с ошибками. Не важно что там под капотом.
  • REST — это новый SOAP
    +1
    Список доступных action-ов?

    Почему вы думаете, что если есть POST /rest-api, то результатом GET /rest-api должна быть коллекция тех ресурсов, что созданы постом?
    Да, это распространенная практика, но не требование. REST требует, чтобы ресурс можно было идентифицировать однозначно, но не требует совпадение URL-ов.

    Запрос:
    POST /rest-api
    Content-Type: application/x.my-cool-rest-api+json
    
    {
      "resource_id": "id",
      "action": "like"
    }
    


    Ответ:
    201 CREATED
    Location: /rest-api/likes/{like_id}
    
  • REST — это новый SOAP
    0
    REST не привязан к HTTP. Вы хоть почтовыми голубями REST можете сделать. Главное чтобы ресурсы имели уникальные идентификаторы и запросы содержали все необходимое для выполнения этого самого запроса.
  • REST — это новый SOAP
    0
    Хотите с помощью PUT обновлять свои ресурсы? Ладно, но Пресвятые Спецификации утверждают, что ввод данных должен представлять собой «полный ресурс» (complete resource), т. е. нужно следовать той же схеме, что и у вывода данных с помощью GET.


    REST требует, чтобы каждый запрос содержал в себе необходимую для выполнения информацию. Если для корректного апдейта требуется только 2 поля, то шлите только 2. В чем проблема?
  • Обзор ноутбука ASUS N580VD
    0
    Печалька, U-проц, видяшка старая.
    Имхо, идеально было бы проц как в этом модели и без отдельной видяхи =)
  • Управление зависимостями в PHP
    +2
    Пусть мои 5 лет в пхп не так уж и много, но за 5 лет не наследовался от вендор-либ ни одного раза. Всегда вопрос решался композицией. А это значит, что всегда можно напилить адаптер для другого вендор-решения или самописной либы.
  • Управление зависимостями в PHP
    0
    А возможно и не придется.
    Вот ради интереса вопрос, сколько раз вы пофиксили или просто столкнулись с критикал багами в сторонних либах за последний год?
  • Суррогаты
    +1
    Так себя называют «партнеры 1С», которые у 1С-а покупают конфигурации дешево, и внедряют/саппортят за дорого
  • Управление зависимостями в PHP
    +1
    Можно разделить либу на 2 пакета. В первом объявить интерфейс, который должен быть реализован (аналог пср-а) и завязать всю логику на интрфейс.
    Во втором пакете можно предоставить реализацию, которая с требованиями к платформе и потенциально конфликтующей реализацией.

    Второй пакет в саггестах у первого.
    Нету конфликтов и лень чето выдумывать? Ставь пакет из саггеста.
    Не устраивает пакет из саггеста? Напили свою реализацию или найди подходящую и сделай адаптер.
  • Управление зависимостями в PHP
    0
    Требования платформы естественно указываются.
    Либа зависит от пср-овского хттп клиента. В suggest-ах может предложить что-то. Но зачем тащить guzzle, если приложение уже что-то использует? Пользователь вашей либы просто наконфигурит какой клиент юзать.
  • Руководство по написанию защищённых PHP-приложений в 2018-м
    +1
    Подготовленных выражений будет достаточно
  • Управление зависимостями в PHP
    0
    Ну и как вам поможет копипаста либы, если либа сложная и багу фиксить всеравно надо?
  • Управление зависимостями в PHP
    0
    Всегда можно форкнуть и пофиксить проблему в своем форке.
  • Критика 1С
    +1
    На самом деле самопись можно сделать намного гибче, чем комбайн все в одном, которым является 1С.

    Нужна аналитика\отчеты — берите инструмент для этого предназначенный (что либо на базе Vertica к примеру, или хотя бы Elastic Search)
    Нужен божественный учет? Стройте Event Sourcing с соответствующими технологиями под капотом.
    В вашем распоряжении весь опен соурс мира. Кто либо, когда либо уже решал все эти проблемы по отдельности. Нужно лишь собрать то, что нужно вам и увязать в единую систему. Это не просто, не быстро и не дешево. Но результат стоящий.

    Проблема в том, что маленькому бизнесу это не по карману. Ему надо что-то, что будет крутиться на компе в подсобке и работать. А потом очень трудно слезть с иглы.
  • Конструирование сайта, защищенного от блокировок
    0
    Нет, ибо длина урлы =)

    Смотрите тогда уж в сторону п2п сайтов
    geektimes.ru/post/284770
    habrahabr.ru/post/112855
  • AMD Ryzen: на что нужно обращать внимание при выборе памяти?
    0
    А чем руководствовались?
  • AMD Ryzen: на что нужно обращать внимание при выборе памяти?
    +1
    Сравните с простым 1600, а не иксовым =)
  • GraphQL — новый взгляд на API. Ч.1
    0
    Вот неплохая статья на тему
    dzone.com/articles/restful-service-design-how-to-overcome-the-crud-na
  • GraphQL — новый взгляд на API. Ч.1
    0
    Что вас смущает?
    1. Ресурс определяется идентификатором /process/123
    2. Запрос содержит информацию, необходимую для выполнения (какой ресурс, и что с ним сделать)
  • Интерфейсы в C#
    0
    Если задача уже исполнена, то зачем об этом писать статью?
  • GraphQL — новый взгляд на API. Ч.1
    +1
    Какие? REST концептуально требует всего 2 вещей:
    1. Чтобы каждый ресурс имел уникальный идентификатор, по которому его можно найти.
    2. Чтобы каждый запрос на получение или изменение ресурса содержал всю информацию, необходимую для его выполнения.
  • Интерфейсы в C#
    0
    Я не писал что интерфейс нужен для каждого класса. Я написал что внедрять их надо до написания непосредственно всех необходимых имплементаций.

    Ясен красен, что интерфейс не нужен для DTO\VO\Entity классов.
    Интерфейсы нужны на границах слоев. В тех местах где ваше приложение взаимодействует с БД, файловой системой, сторонними сервисами. В тех местах, где возможны множественные имплементации.
    Они позволяют вам увидеть как ваше приложение будет работать до того, как вы заимплементите все эти вещи.