Является ли этот метод структуры класса правильным / желаемым?(MVC / C #) - PullRequest
Новая
       11

Является ли этот метод структуры класса правильным / желаемым?(MVC / C #)

1 голос
/ 17 марта 2011

Я создаю приложение MVC, которое немного сложнее, чем я обычно делаю, и я хочу попробовать новую структуру классов. В основном, там много читается. Только 5-10% операций будут вставлены / обновлены в базе данных.

Из-за этого я думаю о создании базовых классов DTO, которые будут возвращены из уровня базы данных. Затем бизнес-объекты наследуются от класса DTO, чтобы расширить базовую структуру со всеми правилами проверки и бизнес-правилами.

Пример: 

namespace Project.DTO
{
    public class Employee
    {
        public string Name;
        public string Surname;
        ...
    }
}

namespace Project
{
    public class Employee : Project.DTO.Employee
    {
        public bool IsValid()
        {
        ...
        }
    }
}

Это хороший подход? То, что я еще не подумал, - это как использовать их внутри MVC, так как «правильный» способ - реализовать классы моделей. Я считаю, что мог бы создать классы моделей, которые также унаследованы от объектов DTO ... но я не уверен.

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

Заранее спасибо!

Ответы [ 2 ]

1 голос
/ 17 марта 2011

Я бы, наверное, использовал совершенно другой подход.Мои основные мысли таковы:

  • Я бы хотел более слабую связь между классами, чтобы мои классовые модели не наследовали от моих объектов DTO
  • Я бы, вероятно, не включил логику проверкив моих модельных классах

Это приведет к тому, что следующая структура будет начинаться с: 

namespace Project.DTO
{
    public class Employee
    {
        public string Name;
        public string Surname;
        ...
    }
}

namespace Project
{
    public class Employee
    {
        public string Name { get; set; }
        public string Surname { get; set; }
    }
}

Когда дело доходит до логики валидации, я бы сделал интерфейс для логики валидации, внедренный в класс Emplyee: 

public interface IValidator<T>
{
    bool IsValid(T objectToInspect);
}
public class Employee
{
    private readonly IValidator<Employee> validator;
    public Employee(IValidator<Employee> validator)
    {
        this.validator = validator;
    }

    public string Name { get; set; }
    public string Surname { get; set; }

    public bool IsValid()
    {
        return validator.IsValid(this);
    }
}

Это открывает ваш дизайн для целого ряда функций, включая использование контейнеров IoC и лучшую поддержку для тестирования.

1 голос
/ 17 марта 2011

Что если проверка должна проверять правило, параметры которого должны поступать из базы данных?У вашей сущности не было бы знаний и способа доступа к этому параметру.

Создание Model / ViewModel - это хорошо, но для валидации обычно требуется более сложная логика, которая потребовала бы выделенных классов - поэтому я бы обычно не реализовывал IsValid вмоя сущность.

Однако вы можете использовать System.Component.DataAnnotation проверочные атрибуты для простых свойств ваших сущностей.

...