Перемещение валидации, HTML-помощники на сервисный уровень в MVC

Question

У нас есть два WebApplication в одном решении MVC, одно для настольного компьютера, а другое для мобильной версии.

Архитектура выглядит так:

• Модель Libraray (включая репозиторий и модель БД)
• Сервисный уровень (бизнес-логика)
• Проект веб-приложения (views, controller, viewModels для рабочего стола)
• Мобильный веб-проект (мобильные представления, контроллер, viewModel)

Я добавил сервисный слой в этот проект http://www.asp.net/mvc/tutorials/validating-with-a-service-layer-cs).

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

• Классы HTML Helper
• Просмотр проверок модели
• Общие функции

Заранее спасибо.

Answer 1

Сначала ответьте на свой вопрос о том, где расположить эти коды

1. Просмотр проверок модели
   Если нет особых причин использовать модель уровня обслуживанияпроверка Я бы посоветовал вам выполнить проверку модели с использованием аннотаций данных в библиотеке моделей.Все, что вам нужно сделать, это добавить некоторые атрибуты к свойствам ваших сущностей, и все будет работать из коробки, включая сообщения проверки (если вы добавляете элементы проверки, используя Html.ValidationMessageFor() или аналогичные) в вашем клиентском виде.

2. Классы HTML Helper
   Классы HTML Helper должны быть частью библиотеки Common UI, если они должны использоваться совместно.Они не принадлежат ни к одному из существующих уровней, потому что все они независимы от уровня представления (веб-приложений).Я полагаю, что ваши помощники HTML будут зависеть от уровня представления, поэтому отдельной библиотеки будет достаточно.

3. Общие функции
   В зависимости от того, где вам нужно использовать общие функции,они также могут быть частью библиотеки моделей или слоя службы.

Как я структурирую свои веб-приложения

Следующее записано в виде слоев.Это, конечно, отдельные проекты во всем решении, поэтому они становятся отдельными сборками.

1. Слой объектов - содержит все общие классы / перечисления / интерфейсы, общие функциональные возможности иPOCO модели приложения, используемые любым уровнем;поэтому на него ссылаются все другие слои

2. Уровень данных - имеет объекты доступа к данным (которые также могут наследоваться от POCO на уровне объектов), которые являются толькоиспользуется на этом уровне и выполняет сопоставление с POCO прикладного уровня;На этом уровне также есть репозитории, поэтому на этот уровень / сборку ссылается следующий уровень (сервис)

3. Сервисный уровень - содержит бизнес-логику и манипулирует классами модели приложения;получает данные из уровня представления и использует уровень данных для управления данными в резервном хранилище (где бы он ни находился - это, конечно, часть хранилища уровня данных для связи с хранилищем)

4. Уровень представления - может быть веб-приложением или чем-то еще;ссылается на слой объектов и служб, чтобы он мог общаться;здесь также создаются любые объекты, представляющие собой только уровень представления (специальные модели представления, необходимые для представлений, но не для служб);

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

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

В случае, если у вас есть два веб-приложения, я бы создал специальный слой с именем Presentation , гдевсе обычные функции HTML, а затем ссылки на него в обоих веб-приложениях.