ASP. NET Код повторного использования ядра для проверки на стороне клиента и на стороне сервера

Question

У меня есть проект на ASP. NET Ядро, использующее страницы Razor. Я использую Entity Framework, но со своей собственной пользовательской конфигурацией сущностей, как показано ниже:

namespace Customer.Data.Relational.Configuration {
   public sealed class CustomerConfiguration {
      public static void Configure(EntityTypeBuilder<CustomerEntity> entity) {
         entity.ToTable("customers")
            .HasKey(k => k.Id)
            .HasName("pk_customers");

         entity.Property(p => p.Id)
            .HasColumnName("customer_id")
            .HasColumnType("bigint")
            .ValueGeneratedOnAdd()
            .IsRequired();

         entity.Property(p => p.Code)
            .HasColumnName("customer_code")
            .HasColumnType("nvarchar(15)")
            .IsRequired();

         entity.Property(p => p.FirstName)
            .HasColumnName("first_name")
            .HasColumnType("nvarchar(100)")
            .IsRequired();

         entity.Property(p => p.LastName)
            .HasColumnName("last_name")
            .HasColumnType("nvarchar(100)")
            .IsRequired();

         entity.Property(p => p.EmailAddress)
            .HasColumnName("email_address")
            .HasColumnType("nvarchar(100)")
            .IsRequired();

         entity.Property(p => p.IsPremierCustomer)
            .HasColumnName("premier_customer")
            .HasColumnType("bit")
            .IsRequired();

         entity.HasIndex(k => k.Code)
            .HasName("uq_customers")
            .IsUnique();

         entity.HasOne(o => o.CustomerType)
            .WithMany()
            .HasForeignKey(f => f.CustomerTypeId)
            .OnDelete(DeleteBehavior.Restrict)
            .HasConstraintName("fk_customers_customer_types");
      }
   }
}

Это позволяет моим классам сущностей быть свободными от любых форм аннотаций (оставляя их просто POCO).

namespace Customer.Entities {
   public class CustomerEntity : IAuditableEntity {
      public long Id { get; set; } = default;

      public string Code {
         get; set;
      }

      public string FirstName {
         get; set;
      }

      public string LastName {
         get; set;
      }

      public string EmailAddress {
         get; set;
      }

      public bool IsPremierCustomer {
         get; set;
      }
   }
}

Я использую FluentValidations для проверки ввода пользователя. Я создал пользовательские классы валидатора. На стороне клиента я включил интеграцию FluentValidation с ASP. NET Core. На стороне сервера я проверяю вручную, вызывая API FluentValidation .

Вопрос - Правильный ли этот подход? Есть ли другой подход, где я могу повторно использовать проверки как на клиенте, так и на сервере? Любые указатели или ссылки приветствуются.

Спасибо.

Answer 1

На высоком уровне это звучит очень похоже на то, как я использую его в данный момент. В проверке на стороне клиента и сервера нет ничего плохого, иногда это необходимо в зависимости от сложности / зависимости правила.

Некоторые приемы, которые могут привести к повторному использованию средства проверки / правила:

• Общие правила можно извлечь в валидаторы свойств или разделить на функциональные проблемы , которые могут помочь с повторным использованием / обслуживаемостью

• Include(validator) может позволить вам сортировать зеркальный график вашего наследования POCO, то есть вы можете повторно использовать правила из валидаторов родительского класса

• Рассмотреть возможность реализации правила на стороне клиента / на сервере устанавливает , чтобы позволить вам избежать двойной обработки / вызова одних и тех же правил на стороне клиента и на стороне сервера, или чтобы ваши службы могли обрабатывать разные сценарии проверки ios (например, стратегия проверки может быть разной для веба) приложение и отдельный автономный сервис, которые используют один и тот же уровень сервиса)

• Настройка управления языком r для переопределения сообщений по умолчанию, чтобы избежать чрезмерного использования расширения WithMessage

С точки зрения пользовательского опыта я стараюсь направить как можно больше на клиентскую сторону. Иногда это означает написание собственных адаптеров на стороне клиента. Это хорошее начало, если вам нужно go по этому маршруту.