MVC3, RavenDB, AutoMapper, IoC / DI и Geese - где я должен использовать свои связанные репозитории? - PullRequest
Новая
       15

MVC3, RavenDB, AutoMapper, IoC / DI и Geese - где я должен использовать свои связанные репозитории?

0 голосов
/ 10 ноября 2011

Я очень новичок в RavenDB и MVC3, в частности, использование (не концепция) IoC. Так что просто предупреждаю, что это будет звучать как вопрос для начинающих.

В итоге: У меня есть модель домена, скажем, это 

public class Goose

В этом классе у меня может быть более сложный объект как свойство 

    public Beak beak { get; set; }

В RavenDB нам справедливо рекомендуется [JsonIgnore] иметь это свойство или не иметь его вообще, а вместо этого иметь ссылочный идентификатор, такой как 

    public String beakId { get; set; }

Где-то по пути в моем приложении MVC3 я захочу просмотреть Goose и, возможно, захочу показать пользователю что-то о Goose и его клюве (это должен быть Билл?). Так что да, мне нужна модель представления, верно? 

public class GooseModel
{
    public String BeakColour { get; set; }
    public String BeakLength { get; set; }
    ...etc
}

Правильно, если предположить, что у меня есть несколько GooseRepository и несколько BeakRepository, вот простой вопрос ...

Я в классе GooseController и загружаю Goose для просмотра. В какой момент я использую BeakRepository, и кто должен знать об этом? GooseController знает о GooseRepository и загружает Goose по идентификатору. На этом этапе у нас может быть какое-то свойство внутри класса Goose, которое представляет весь клюв, но я действительно не хочу вставлять BeakRepository в GooseRepository, не так ли? Итак, возможно, когда я создаю GooseModel из Goose, который я обнаружил, я могу получить свойства GooseModel для BeakColour и BeakLength, как? Что ж, мне нравится AutoMapper, так что я думаю, что моя карта For GooseModel от Goose использует BeakRepository для поиска Beak, а затем извлекает два свойства Beak для заполнения полей GooseModel ... это тоже кажется неправильным ... так что же осталось? GooseController ... должен ли контроллер Goose знать о BeakRespository, а затем найти и установить BeakColour и BeakLength !? это, конечно, тоже кажется совершенно неправильным ..

Так, где это сделано? Контроллер, объект домена, маппер или еще где-то? Возможно, у меня должен быть частичный вид Type Beak, который используется в представлении Goose? ..

Ответы [ 2 ]

1 голос
/ 10 ноября 2011

Хм, ... читая ваш вопрос, я настоятельно рекомендую вам забыть о слое сервиса и слое репозитория. Если у вас нет веских причин для их сохранения (тестирование не входит в их число, поскольку в RavenDB есть хранилище EmbeddableDocumentStore, которое является быстрым и простым), потяните их, чтобы воспользоваться некоторыми очень приятными функциями RavenDB.

Я на самом деле написал пост о том, почему я думаю, что вам следует избегать этих слоев: http://daniellang.net/keep-your-code-simple/ Речь идет о NHibernate, но концепции применимы и здесь.

Необходимость денормализации свойств BeakColor и BeakLength в вашем документе Goose зависит от потребностей ваших приложений. Если вы чувствуете себя комфортно с термином «совокупный корень», то практическое правило заключается в том, что это, как правило, ваши документы. Если вы не уверены, стоит ли применять денормализацию, избегайте ее и используйте вместо нее .Include(goose => goose.Beak) при загрузке вашего Goose.

Пожалуйста, дайте мне знать, если это имеет смысл для вас.

1 голос
/ 10 ноября 2011

Я склонен объединять такую ​​логику в сервис / бизнес-уровень (GooseService), который затем внедряю в контроллер.ваш сервисный уровень может взять GooseRepository и BeakRepository и вернуть разрешенный объект, который сопоставил GooseViewModel вместе.

...