Организация классов с помощью шаблона разработки репозитория
Нет никакого способа сделать это в IE6/IE7/IE8. Управление оттянуто приложением, и IE просто не тянет его тот путь. Ваш лучший выбор состоит в том, чтобы реализовать Ваше собственное выпадающее через простой HTML/CSS/JavaScript, если настолько важно иметь выпадающую одну ширину и список другая ширина.
4 ответа
Существует довольно существенное расхождение между средней стратегией доступа к данным MVC и пониманием шаблона репозитория в рамках Domain-Driven-Design.
Большинство примеров вы увидите для ASP.Net MVC - это всего лишь небольшой шаг вперед по сравнению с ActiveRecord, использующим объекты репозитория для каждой сущности. На самом деле они реализуют своего рода шлюз табличных данных и используют слово Repository вместо Gateway.
В этом нет ничего плохого для многих приложений, и я обычно запускал новые приложения с тем же подходом, пока не смог докажи, что мне нужно что-то другое. Однако принципы доменно-ориентированного проектирования, из которых обычно заимствуется идея репозитория, позволят вам идентифицировать агрегированные корни и консолидировать доступ к данным для этих дочерних объектов через агрегированный корень ' s репозиторий. Это позволяет вам устанавливать границы вокруг изменений состояния в вашем хранилище данных и, среди прочего, может помочь в принудительном применении транзакционных изменений.
Отредактировано для добавления: в вашем примере маловероятно, что вы измените какой-либо из этих дочерних объектов изолированно от родительского, поэтому я бы хотел сказать, что «тема» - это совокупный корень вашего домена.
Я думаю, это зависит от того, как вы собираетесь получить доступ к своим данным. При внесении изменений вы всегда будете просматривать тему с ее комментариями и, наоборот, для подобных (32) элементов пользовательского интерфейса комментариев.
Таким образом, ваша тема становится совокупным корнем , и для этого вам нужен только один репозиторий.
Одна вещь, которую следует учитывать: если у вас много мелких вещей, вам нужен только очень узкий доступ, например, список опций для раскрывающегося списка, вам действительно не нужен полноценный репозиторий для этого. Проблема заключается в том, что как только вы передадите 20 сущностей, у вас будет 20 интерфейсов и 20 репозиториев, о которых нужно подумать в своем решении.
Очень прагматично иметь репозитории только для ваших агрегированных корней и хранить вместе репозитории других типов значений. Например DropdownlistRepository или что-то в этом роде.
Наконец, на этапе вашего проекта проблемы с производительностью просто не имеют значения, и получение всего графа объектов для «Тема», вероятно, не так уж и плохо с точки зрения производительности. Не усложняйте ситуацию, если вы используете ORM-преобразователь, он должен иметь возможность предоставлять вам тему каждый раз, когда она вам понадобится, со всеми ее дочерними объектами, загруженными лениво.
На мой взгляд, он должен находиться в собственном репозитории ...
Изменить:
Посредник между доменом и данными отображение слоев с использованием коллекции, подобной интерфейс для доступа к домену объекты.
Это позволяет, если вы заинтересованы, использовать общий репозиторий, такой как этот пример , что означает меньше кода ...
Глядя на учебник NerdDinner , кажется, что у них есть репозиторий для каждой сущности.
Когда вы думаете об этом, это имеет смысл. Будут случаи, когда вы захотите контролировать, когда загружать суб-объекты.