Ссылки на сущности со службами и хранилищами - PullRequest
1 голос
/ 31 мая 2010

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

Текущая архитектура основана на AppServer на основе WCF, базе данных MS SQL и клиентах WPF / WCF, которые обращаются к AppServer.

У меня есть 3 сущности, проживание, квартира и гость. Пребывание имеет ссылку на 1 квартиру и 1 гость. У каждого из 3-х сущностей есть свой собственный репозиторий (поскольку, насколько я понимаю, они являются корневыми сущностями). Классы сущностей являются POCO и используются на сервере, а также на клиенте. Репозитории используют OR / Mapper для внутреннего использования (на данный момент Entity Framework).

В настоящее время существует 3 WCF-Сервиса, по одному на каждую сущность, которая обрабатывает CRUD-операции ... больше будет сделано вовремя.

Теперь к моей проблеме ... На каком уровне должна осуществляться ссылка на сущности? Репозитории не должны зависеть друг от друга (для легкой замены, но если это необходимо, они могут свободно зависеть друг от друга, поскольку я уже использую LightCore в качестве DI-контейнера). Насколько я понимаю, ссылки могут быть установлены либо в Репозитариях, либо в Сервисах.

Что было бы «правильным» или более элегантным способом?

Может быть, я что-то неправильно понял, но ссылки не кажутся действительно эффективными. Например, если у меня 10000 путевок, 15000 гостей и 150 апартаментов. Если я хочу вернуть 500 пребываний, включая связанных гостей из службы (500 кажется разумным, хотя я хотел бы вернуть больше), то это будет до 500 * 15 000 = 7,5 млн. Итераций. Это не кажется очень эффективным. Конечно, это можно кэшировать, но кэширование только помогает до определенного момента.

Или я где-то заблуждаюсь в своем дизайне? Будем благодарны за любые советы:)

[Редактировать] Я все еще не уверен, как поступить с моим дизайном, поэтому любая помощь будет принята с благодарностью.

1 Ответ

0 голосов
/ 03 июня 2010

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

Например, чтобы создать новую книгу, я бы использовал операцию создания в хранилище книг, но чтобы связать новую книгу с существующим автором (скажем, по какой-то причине этот сценарий существует), у меня может быть метод для моего автора хранилище называется AddBookToAuthor (int authorId, Book book). Это позволит эффективно найти автора, о котором идет речь, добавить книгу в коллекцию книг автора, а если эта книга - новая книга, фактически создать новый экземпляр книги в хранилище данных.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...