Как правило, в решениях .NET лучше всего разделять код на разные проекты, только если этот код может быть полезен для других приложений или когда сам код представляет собой полное решение некоторой проблемной области. Библиотека классов, на которую ссылается только один проект приложения, является пустой тратой.
Кроме того, имейте в виду, что .NET не допускает циклические ссылки между объектами в двух разных сборках (что обычно переводит один в один с проектами).
В вашем примере я бы посоветовал вам рассмотреть одну библиотеку классов для модели, услуг и безопасности ... в зависимости от того, что вы имеете в виду, когда говорите "услуги".
В большинстве случаев доступ к данным в некоторой степени связан с концепцией модели MVC, поэтому вы можете рассмотреть возможность размещения доступа к данным и там ... но если у вас есть очень четко отделенный слой доступа к данным, он может вписаться собственная библиотека классов.
Контроллеры и представления обычно должны входить в веб-проект напрямую.
В общем, мой совет - разбивать вещи на отдельные проекты ТОЛЬКО тогда, когда у вас есть реальная «потребность» в этом. Но сборки и проекты НЕ являются хорошим способом представления слоев или уровней в большинстве приложений. Это логические концепции, которые не всегда хорошо соответствуют физической структуре проекта.
Если вы хорошо спроектировали свои классы и избежали тесной связи, вы можете обычно перемещать код в библиотеки классов позже, если возникнет реальная необходимость.