Я использую архитектуру N-многоуровневого приложения с доменными именами с EF code first в моем недавнем проекте, я определил свои контракты Repository В слое Domain.
Основной контракт, чтобы сделать другое Repositories менее подробным:
public interface IRepository<TEntity, in TKey> where TEntity : class
{
TEntity GetById(TKey id);
void Create(TEntity entity);
void Update(TEntity entity);
void Delete(TEntity entity);
}
И специализированный Repositories за каждый Aggregation root, например:
public interface IOrderRepository : IRepository<Order, int>
{
IEnumerable<Order> FindAllOrders();
IEnumerable<Order> Find(string text);
//other methods that return Order aggregation root
}
Как вы видите, все эти методы зависят от Domain entities.
Но в некоторых случаях приложению UI нужны некоторые данные, которые не являются Entity, данные могут быть сделаны из двух или более данных энтерита (View-Model s), в этих случаях я определяю View-Model в Application layer, поскольку они тесно зависят от потребностей Application's, а не от Domain.
Итак, я думаю, что у меня есть 2 способа показать данные как View-Models в UI:
- Оставьте специализированный
RepositoryтолькоEntitiesи сопоставьте результаты методаRepositoriesсView-Models, когда я хочу показать пользователю (обычноApplication layer). - Добавьте несколько методов к моей специализированной
Repositories, которые возвращают их результаты какView-Modelsнапрямую, и используют эти возвращаемые значения вApplication layer, а затемUI(эти специализированные контрактыRepositories, которые я называю ихReadonly Repository Contracts, введитеApplication layerв отличие от другого контрактаRepositories'e, который помещается вDomain).![enter image description here]()
Предположим, my UI нуждается в View-Model с 3 или 4 свойствами (от 3 или 4 большой Entities).
Эти данные могут быть сгенерированы с простой проекцией, но в случае 1, поскольку мои методы не могли получить доступ к View-Models, я должен получить все поля из всех 3 или 4 таблиц, иногда с огромными объединениями, а затем сопоставьте результаты с View-Models.
Но в случае 2 я мог просто использовать проекцию и непосредственно заполнить View-Model.
Итак, я думаю, что с точки зрения производительности случай 2 лучше, чем случай 1. но я читал, что Repository должен зависеть от Entities, а не View-Models в проектной точке.
Есть ли лучший способ, который не приводит к тому, что уровень Domain зависит от Application layer, а также не влияет на производительность? или допустимо, что для чтения запросов мой Repositories зависит от View-Models? (case2)