Шаблон для общедоступных и внутренних интерфейсов на бизнес-объектах
Я хотел бы создать модель домена с использованием внутренних интерфейсов
а затем создать ограниченные публичные интерфейсы (для пользователей сборки)
Пока это возможно в CSharp, я продолжаю работать в грязном коде, связанном с параллельными интерфейсами:
public interface IAccount { IList<ITran> Transactions { get; } }
internal interface IAccountInternal : IAccount { IList<ITranInternal> Transactions { get; } }
internal class Account : IAccountInternal { }
здесь реализация учетной записи становится очень грязной, поскольку существует множество коллекций, которым нужны два интерфейса и т.д.
Кроме того, я хотел бы гарантировать, что публичные интерфейсы реализованы с использованием внутренних интерфейсов (в отличие от прямого доступа к конкретным классам)
Это должен быть общий сценарий, может ли кто-нибудь рекомендовать чистый подход?
с использованием общей ковариации интерфейса в dot net 4.0 Мне удалось очистить вещи (обратите внимание на модификатор "out" на параметр T)
public interface IListReadOnly<out T> : IEnumerable<T> {
int Count { get; }
T this[int index] { get; }
}//class
это позволяет мне возвращать коллекции внутренних объектов, типизированных как общедоступные объекты, потому что:
public interface IPublic { }
internal interface IPrivate : IPublic { }
теперь это работает:
private IListReadOnly<IPrivate> list = ...
public IListReadOnly<IPublic> List { get { return list; } }
Это кажется плохой идеей, эта модель кажется очень сложной.
Моя первая мысль - уменьшить потребность в внутренних интерфейсах. Если вы используете их для модульного тестирования, я бы рекомендовал только тестировать внешний (публичный) интерфейс и, по сути, полностью отказаться от использования внутренних интерфейсов.
Кроме того, если вы можете уточнить необходимость в модели внутреннего домена, это может помочь другим лучше ответить на ваш вопрос.
