Инкапсуляция моделей ASP.NET MVC как многоразовой сборки

Question

Есть ли принятый / ожидаемый наилучший способ для инкапсуляции "модельной" части ASP.NET MVC в сборку многократного использования?

В качестве технического упражнения я хочу использовать один и тот же уровень бизнес / персистентности в разных системах. Например, скомпилируйте одну и ту же сборку как в приложении ASP.NET MVC, так и в традиционной службе Windows.

Я думаю реализовать мои модели (и EntityFramework / DbContext / etc) в отдельной сборке. Тогда мой проект MVC полностью пропустил бы папку «Модели», и мои контроллеры ссылались бы на код в «сборке моделей». Я всегда предпочитал ViewModels над реальными бизнес-объектами в качестве «целей» Views, поэтому я очень рад, что все мои Views строго типизированы для объектов ViewModel вместо объектов Model в любом случае.

1. Это общий подход?
2. Нарушает ли это принцип «соглашения о конфигурации» ASP.NET MVC?
3. Существуют ли конкретные преимущества MVC, которые я бы потерял, если бы использовал этот подход?
4. Есть ли другие неприятные подводные камни в этом подходе?

Я достаточно комфортный ветеран ASP.NET, C # и служб Windows, но довольно новичок в ASP.NET MVC. Извиняюсь, если это дублирующий вопрос; Большинство вопросов «многократного использования MVC» сосредоточены на компонентах пользовательского интерфейса, а не на целом уровне бизнеса / персистентности. Как всегда, заранее спасибо за ваши идеи!

Answer 1

Да, именно так я видел, как развивались многие системы. В итоге вы получите «бизнес-уровень», который может работать с REST-over-WCF-on-IIS так же хорошо, как и с любым другим.

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

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