Реализация уровня служб в архитектуре MVC
Я использую VIM в значительной степени исключительно теперь.
я раньше использовал Vim для редактирования и Редактора VS для отладки. Это, вероятно, кажется немного сумасшедшим, но я нашел парадигму Vi (макросы, основанное на клавише Home редактирование и т.д.) таким повышением моей производительности, то редактирование в VS было paintful.
Благодаря Viemu, я не должен даже больше делать переключения. Это еще не идеальное решение (завершение кода иногда не так изящно как в собственной энергии, и макро-запись не прекрасна), но это намного лучше, чем переключение назад и вперед постоянно.
кривая обучения для Vim, вероятно, преувеличена. Я думаю, как только Вы входите в него, это довольно интуитивно.
3 ответа
Насколько я понимаю этот вопрос, на самом деле есть две вещи, на которые следует ответить:
A) Я бы предпочел разделить «Службу» на « CustomerService »и« OrderService », другими словами, сгруппированные по концепциям предметной области.
B) Во-вторых, я бы использовал внедрение зависимостей, чтобы получить нужную услугу прямо там, где она мне нужна, поэтому я в основном использую alt 1. Добавленная абстракция в альтернативе 2 не представляет для меня никакой дополнительной ценности, так как контейнер IoC выполняет важную роль.
Использование «фасада» - это один из подходов:
«Фасад - это объект, который обеспечивает упрощенный интерфейс для большей части кода»
Лично я предпочитаю №2, и да, это обычно настраивается в начальной загрузке, или зависимости разрешаются с использованием какого-то контейнера IoC, чтобы предоставить вам реальные конкретные экземпляры.
Я также хотел бы прокомментировать, и да, я понимаю, что это, вероятно, больше личное предпочтение. Старайтесь избегать использования названия слоя «Сервис» для этих объектов. называйте их репозиториями или чем-то еще. если вы используете сервис, этот термин становится перегруженным ... потому что тогда разработчики спрашивают: «Вы имеете в виду сервис отдыха или wcf?». поверьте мне, мы сделали это в недавнем проекте и все время путаемся, когда говорим о том, где внести изменения в код :-P