Архитектура приложения ASP.net MVC для использования репозиториев и сервисов

Недавно я начал читать об ASP.net MVC, и, увлекшись этой концепцией, я начал переносить весь свой проект веб-формы в MVC, но мне трудно сохранить мой контроллер тощим, даже после того, как я следовал всем хорошим советам (или, может быть, я просто не понимаю...). На веб-сайте, с которым я работаю, есть статьи, видео, цитаты... и у каждого из этих объектов есть категории, комментарии, изображения, которые могут быть связаны с ним. Я использую Linq to sql для операций с базой данных, и для каждой из этих сущностей у меня есть репозиторий, и для каждого репозитория я создаю службу, которая будет использоваться в контроллере.

так что я -

  • СтатьяРепозиторий
  • СтатьяКатегорияРепозиторий
  • СтатьяКомментарийРепозиторий

и соответствующий сервис

  • СтатьяСервис
  • СтатьяКатегорияСервис ...

вы видите картину.

Моя проблема заключается в том, что у меня есть один контроллер для статьи, категории и комментария, потому что я думал, что обработка ArticleController всего этого может иметь смысл, но теперь мне нужно передать все службы, необходимые конструктору контроллера. Поэтому я хотел бы знать, что это такое, что я делаю неправильно. Мои услуги не разработаны должным образом? Должен ли я создать более крупный сервис, чтобы инкапсулировать более мелкие сервисы и использовать их в моем контроллере? или у меня должен быть Контроллер категорий статей и Контроллер комментариев к статьям?

Страница, просматриваемая пользователем, состоит из всего этого: статьи для просмотра, комментариев, связанных с ней, списка категорий, к которым она применяется ... как я могу эффективно разбить контроллер, чтобы он оставался «тощим». "и решить мою головную боль?

Спасибо! Надеюсь, мой вопрос не слишком длинный, чтобы его читали...


controller repository-pattern design-patterns asp.net-mvc service
person ak3nat0n    schedule 23.03.2010    source источник
comment
Мои контроллеры в настоящее время имеют 6-10+ зависимостей, которые я передаю конструктору. Это также приводит к громоздким контроллерам, но это только потому, что я часто показываю много данных из разных источников на одной странице, и все эти данные должны быть загружены в модель представления.   -  person Todd Smith    schedule 24.03.2010

Ответы (2)


arrow_upward
7
arrow_downward

Это побочный эффект использования шаблона единой ответственности. Если каждый класс предназначен только для одной цели, то в итоге вы получите множество классов. Это хорошо. Не бойтесь этого. В долгосрочной перспективе это значительно облегчит вам жизнь, когда дело доходит до замены компонентов, а также отладки компонентов вашей системы, которые не работают.

Лично я предпочитаю размещать больше логики моей предметной области в реальных объектах предметной области (например, article.AddComment(comment) вместо articleCommentService.AddComment(article, comment)), но ваш подход также отлично подходит.

person Kevin Pang    schedule 23.03.2010
comment
если я покажу статью с соответствующими категориями-комментариями-изображениями, нужно ли мне помещать их все в один контроллер, чтобы он работал? Как быть с таким сложным объектом, как статья? Я чувствую, что использование вашего подхода (категории и комментарии являются частью домена статьи) может помочь мне решить проблему, уводя меня от SRP... - person ak3nat0n; 24.03.2010
comment
У меня был бы класс статьи со свойствами для его категорий, комментариев, изображений и т. д. Они будут загружаться отложенно, чтобы мне не требовалось извлекать весь граф объектов из БД, когда мне могут понадобиться только метаданные статьи. Это отвечает на ваш вопрос? Я не уверен, что понимаю, как это нарушает SRP. SRP не означает, что связанные сущности не могут ссылаться друг на друга. - person Kevin Pang; 24.03.2010
comment
Вы правы, они могут ссылаться друг на друга, я не думал об этом таким образом. Спасибо! - person ak3nat0n; 24.03.2010

arrow_upward
2
arrow_downward

Я думаю, вы движетесь в правильном направлении. Вопрос в том, как создать экземпляр ваших сервисов? Я не гуру MVC.NET, но сделал множество сервис-ориентированных Java-проектов и именно тот шаблон, который вы обсуждаете.

В мире Java мы обычно использовали Spring для внедрения одноэлементных компонентов.

1) Вы можете сделать то же самое в .NET, используя фреймворки внедрения зависимостей.

2) Вы можете создавать экземпляры сервисов по мере необходимости в методе, если они достаточно легкие.

3) Вы можете создавать статические члены службы в каждом контроллере, если вы пишете их как потокобезопасные, чтобы уменьшить отток объектов. Именно этот подход я использую во многих случаях.

4) Вы даже можете создать простую глобальную фабрику сервисов, доступную для всех контроллеров, которая может быть просто классом синглетонов.

Также погуглите о внедрении зависимостей .NET.

person codenheim    schedule 23.03.2010