Два членских перечисления по сравнению с булевым значением
Это зависит от потребностей Вашего приложения. Если это - большая проблема загрузить все Проекты для данного Редактора, то попробуйте ленивый шаблон загрузки как Виртуальный Прокси .
Относительно ленивой загрузки членских Редакторов Проекта, если Вы используете Виртуальный Прокси, я не вижу проблемы ввести прокси с EditorRepository, так как я не полагаю, что прокси часть домена.
, Если Вы разделяете Агрегат, можно заняться расследованиями Единица работы шаблон как одно решение атомарности. Эта проблема, тем не менее, не уникальна для DDD, и я уверен, что существуют другие решения для транзакционного поведения.
3 ответа
В своей книге Рефакторинг Мартин Фаулер объясняет, почему он считает перечисления запахом кода, и я могу только согласиться. В вашем примере лучше было бы создать абстрактный класс Room:
public abstract class Room
{
public string Name { get; set; }
public abstract bool Bookable { get; }
}
Затем вы можете создать производные классы BookableRoom и NonBookableRoom.
public class BookableRoom : Room
{
public override bool Bookable
{
get { return true; }
}
}
public class NonBookableRoom : Room
{
public override bool Bookable
{
get { return false; }
}
}
Просто для удобства чтения и понимания кода я выберу enum вместо логического.
Сравните BookingStatus.Bookable ] и true , вы, конечно, поймете больше, прочитав BookingStatus.Bookable .
Также как то, что упоминалось в fforw, на случай, если в будущем вам может потребоваться добавить больше параметров, enum будет легче изменить.
Ih есть вероятность, что в будущем может быть больше, чем два начальных параметра, добавление третьего параметра в перечисление требует гораздо меньше работы, чем изменение всех bool на enum.