• Архитектура модульных React + Redux приложений 2. Ядро

    • Tutorial
    В первой части я уделил внимание только общей концепции: редюсеры, компоненты и экшны чаще меняются одновременно, а не по отдельности, поэтому и группировать и их целесообразнее по модулям, а не по отдельным папкам actions, components, reducers. Также к модулям были предъявлены требования:

    1. быть независимыми друг от друга
    2. взаимодействовать с приложением через API ядра

    В этой части я расскажу о структуре ядра, подходящей для разработки data-driven систем.
    Читать дальше →
    • +12
    • 6,5k
    • 3
  • Архитектура модульных React + Redux приложений

    • Tutorial


    Большинство разработчиков начинает знакомство с Redux с Todo List Project. Это приложение имеет следующую структуру:

    actions/
      todos.js
    components/
      todos/
        TodoItem.js
        ...
    constants/
      actionTypes.js
    reducers/
      todos.js
    index.js
    rootReducer.js

    На первый взгляд такая организация кода кажется логичной, ведь она напоминает стандартные соглашения многих backend MVC-фреймворков:

    app/
      controllers/
      models/
      views/

    На самом деле, это неудачный выбор как для MVC, так и для React+Redux приложений по следующим причинам:

    1. С ростом приложения следить за взаимосвязью между компонентами, экшнами и редюсерами становится крайне сложно
    2. При изменении экшна или компонента с большой вероятностью потребуется внести изменения и в редюсер. Если количество файлов велико, скролить IDE вверх/вниз не удобно
    3. Такая структура потворствует копипасте в редюсерах

    Не удивительно, что многие авторы(раз, два, три) советуют структурировать приложение по «функциональности» (by feature).
    Читать дальше →
  • Введение в React и Redux для бекенд-разработчиков



      Если вы как я долгое время считали, что JavaScript – это такой «игрушечный» язык на котором пишут анимашки для менюшек и падающие снежинки на форумах под новый год, а потом очнулись в 2016 году с мыслями WTF: react, flux redux, webpack, babel,… не отчаивайтесь. Вы не одиноки. Материалов по современному фронтенду в сети много, даже слишком много. Под катом еще одно альтернативное мнение о том, каково это учить JavaScript в 2016 году.
      Стань модным
    • Функциональный C#

        C# — язык мультипарадигмальный. В последнее время крен наметился в сторону функциональщины. Можно пойти дальше и добавить еще немного методов-расширений, позволяющих писать меньше кода, не «залезая» при этом на территорию F#.
        Читать дальше →
      • Шаблон проектирования «Спецификация» в C#

          «Спецификация» в программировании — это шаблон проектирования, посредством которого представление правил бизнес логики может быть преобразовано в виде цепочки объектов, связанных операциями булевой логики.

          Я познакомился с этим термином в процессе чтения DDD Эванса. На Хабре есть статьи с описанием практического применения паттерна и проблем, возникающих в процессе реализации.

          Если коротко, основное преимущество от использования «спецификаций» в том, чтобы иметь одно понятное место, в котором сосредоточены все правила фильтрации объектов предметной модели, вместо тысячи размазанных ровным слоем по приложению лямбда-выражений.

          Классическая реализация шаблона проектирования выглядит так:

          public interface ISpecification
          {
              bool IsSatisfiedBy(object candidate);
          }
          

          Что с ним не так применительно к C#?


          1. Есть Expression<Func<T, bool>> и Func<T, bool>>, сигнатура которых совпадает с IsSatisfiedBy
          2. Есть Extension-методы. alexanderzaytsev с помощью них делает вот так:

            public class UserQueryExtensions 
            {
              public static IQueryable<User> WhereGroupNameIs(this IQueryable<User> users,
            string name)
              {
                  return users.Where(u => u.GroupName == name);
              }
            }
            

          3. А еще можно реализовать вот такую надстройку над LINQ:

            public abstract class Specification<T>
            {
              public bool IsSatisfiedBy(T item)
              {
                return SatisfyingElementsFrom(new[] { item }.AsQueryable()).Any();
              }
            
               public abstract IQueryable<T> SatisfyingElementsFrom(IQueryable<T> candidates);
            }
            

          В конечном итоге возникает вопрос: стоит ли в C# пользоваться шаблоном десятилетней давности из мира Java и как его реализовать?

          Читать дальше →
        • Union Type, TPT, DDD, ORM и RDBMS


            Объединения и pattern-matching широко используются в функциональном программировании для повышения надежности и выразительности программ.

            Классический пример удачного использования объединений для моделирования бизнес-процессов – корзина и состояние заказа. Пользователь в праве добавлять и убирать товары, пока не оплатил заказ. Но сама операция модификации оплаченного заказа лишена смысла. Также лишена смысла операция Remove для пустой корзины. Тогда логично вместо общего класса Cart определить интерфейс ICartState и объявить по одной реализации для каждого состояния. Более подробно данный подход изложен текстом здесь и в видео-формате вот тут.

            Недавно у нас возникла задача спроектировать структуру БД для специализированной CRM/ERP. Первый подход к моделированию договоров оказался не удачным, из-за того что сторонами договоров могут выступать как физические, так и юридические лица из России и других стран мира. ИНН необходим продавцу, чтобы получить оплату, но не всегда нужен полкупателю (для идентификации личности чаще используются паспортные данные). Форматы реквизитов отечественных и зарубежных юр.лиц не совпадают. Не помогало делу и то, что ИП являются физическими лицами, но «прикидываются» юридическими.

            На ретроспективе мы разобрали ошибки первоначального дизайна и наметили направление рефакторинга. Всех, заинтересовавшихся нашей историей, прошу под кат.
            Читать дальше →
          • DotNext — Moscow 2016. Как это было



              Впервые я побывал на «Дотнексте» летом этого года в Питере. Тогда меня привлекли имена Дино Эспозито и Саши Гольдштейна в списке докладчиков. По книге Дино я когда-то давно осваивал ASP.NET. Pro .NET Performance не читал, но отзывы слышал лишь позитивные. Никогда не считал performance своей сильной стороной, а необходимость сталкиваться по работе с оптимизацией производительности стала возникать довольно часто. Вдобавок, на тот момент у меня были смешанные чувства по отношению к .NET Core. Хотелось узнать, что думают другие по этому поводу. Решающим фактором, конечно же, стало желание девушки съездить в Питер на пару деньков. Мы поехали и не пожалели:)

              С Москвой все было сложнее – этот город я недолюбливаю примерно так-же, как зиму в России. Чашу весов на этот раз сдвинули доклады C++ через C#, Моя жизнь с актерами, Squeezing the Hardware to Make Performance Juice и присутствие на конференции сотрудника Stack Overflow. Каждый из них был интересен в практическом плане, так что поездка предстояла не увеселительная, а рабочая.

              мои впечатления
            • Устранение дублирования Where Expressions в приложении

                Допустим, у вас есть товары и категории. В какой-то момент клиент сообщает, что для категорий с рейтингом > 50 необходимо использовать другие бизнес-процессы. У вас достаточно опыта и вы понимаете, что где сегодня 50 завтра будет 127.37 и хотите избежать появления магических чисел в коде, поэтому делаете так:

                    public class Category : HasIdBase<int>
                    {
                        public static readonly Expression<Func<Category, bool>> NiceRating = x => x.Rating > 50;
                
                       //...
                    }
                
                    var niceCategories = db.Query<Category>.Where(Category.NiceRating);
                

                К сожалению, этот номер не пройдет, если вы хотите выбрать продукты из соответствующих категорий, потому что NiceRating имеет тип Expression<Func<Category, bool>>, а в случае с Product нам потребуется Expression<Func<Product, bool>>. То есть, необходимо осуществить преобразование Expression<Func<Category, bool>> => Expression<Func<Product, bool>>.

                    public class Product: HasIdBase<int>
                    {
                        public virtual Category Category { get; set; }
                
                       //...
                    }
                
                    var niceProductsCompilationError = db.Query<Product>.Where(Category.NiceRating); // так нельзя!
                

                К счастью, осуществить это довольно просто!
                Код под катом
              • Как мы попробовали DDD, CQRS и Event Sourcing и какие выводы сделали

                  Вот уже около трех лет я использую в работе принципы Spec By Example, Domain Driven Design и CQRS. За это время накопился опыт практического применения этих практик на платформе .NET. В статье я хочу поделиться нашим опытом и выводами, которые могут быть полезными командам, желающим использовать эти подходы в разработке.

                  Факты, цифры, код
                • Немного о нетрадиционном маппинге

                    Многие знают про отличную библиотеку AutoMapper. С преобразованием Entity -> Dto проблем обычно не возникает. Но как обрабатывать обратный маппинг в случае, когда в API приходит корень агрегации? Хорошо, если read и write — контексты разделены и писать можно из Dto. Чаще, однако, нужно выбрать соответствующие сущности из ORM по Id и сохранить агрегат целиком. Занятие это муторное, однако зачастую поддающееся автоматизации.
                    Особый TypeConverter увидеть желаешь