Блог

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

В заключение: у меня есть модель предметной области, допустим, это

 public class Goose
  

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

     public Beak beak { get; set; }
  

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

     public String beakId { get; set; }
  

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

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

Верно, итак, предполагая, что у меня есть какое-то хранилище GooseRepository и какое-то хранилище BeakRepository, вот простой вопрос….

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

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

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

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

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

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

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