Бизнес-объект - должны ли списки отображаться только как ReadOnlyCollections? - PullRequest
Новая
       19

Бизнес-объект - должны ли списки отображаться только как ReadOnlyCollections?

2 голосов
/ 24 марта 2011

Пытаясь централизовать, как элементы добавляются или удаляются из моих классов бизнес-сущностей, я перешел к модели, в которой все списки представлены только как ReadOnlyCollections, и я предоставляю методы Add и Remove для управления объектами в списке.

Вот пример: 

public class Course
{
    public string Name{get; set;}
}

public class Student
{
    private List<Course>_courses = new List<Course>();
    public string Name{get; set;}
    public ReadOnlyCollection<Course> Courses {
        get{ return _courses.AsReadOnly();}
    }
    public void Add(Course course)
    {
        if (course != null && _courses.Count <= 3)
        {
            _courses.Add(course);
        }
    }
    public bool Remove(Course course)
    {
        bool removed = false;
        if (course != null && _courses.Count <= 3)
        {
            removed = _courses.Remove(course);
        }
        return removed;
    }
}

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

Некоторая предыстория: приложение, с которым я работаю, является приложением Asp.net, где списки использовались ранее как список, что приводило ко всем видамспособы, которыми Курсы были добавлены к Студенту (в некоторых местах проверка была сделана, а в других проверка не была сделана).

Но мой вопрос: является ли вышеупомянутое хорошей идеей?

Ответы [ 3 ]

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

Да, это хороший подход, по моему мнению, вы ничего не делаете, кроме украшения своего списка, и это лучше, чем реализация вашего собственного IList (поскольку вы сохраняете много строк кода, даже если вы теряете более элегантный способдля перебора объектов курса).

Вы можете рассмотреть возможность получения объекта стратегии проверки, поскольку в будущем у вас может появиться новое требование, например: новый тип учащихся, который может иметь более 3 курсов,и т.д.

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

Я бы сказал, что это хорошая идея, когда добавление / удаление необходимо контролировать так, как вы предлагаете, например, для проверки бизнес-правил. В противном случае, как вы знаете из предыдущего кода, на самом деле нет способа гарантировать, что проверка будет выполнена.

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

Я полагаю, что другой подход мог бы заключаться в том, чтобы иметь собственный потомок IList<T>, который имеет общий код управления для своих методов Add() и Remove(), который уведомляет систему о том, что происходит. Что-то вроде экспонирования события, которое возникает перед тем, как вызывается внутренняя логика этих методов. Тогда класс Student будет предоставлять делегата или что-то в этом роде (извините за расплывчатость, я сегодня очень закодирован) при создании экземпляра _courses для применения бизнес-логики к событию и отмены операции (выбрасываю исключение, я думаю, ) если проверка бизнеса не удалась.

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

0 голосов
/ 24 марта 2011

Я делал это в прошлом и сожалел об этом: лучше использовать различные классы для чтения доменных объектов, чем те, которые вы используете для их изменения.

Например, используйте богатый поведением класс домена Student, который ревниво охраняет владение курсами - он не должен их вообще раскрывать, если за них отвечает студент, - и StudentDataTransferObject (или ViewModel) это обеспечивает простой список строк курсов (или словарь, когда вам нужны идентификаторы) для заполнения интерфейсов.

...