Добрый день, уважаемые веб-мастера. Сегодня я бы хотел обсудить архитектуру ASP.NET MVC приложений, в случае, если вы делаете простой сайт.
Небольшой дисклеймер. Я — джуниор (и то, в лучшем случае). А поэтому, всё, что написано ниже, может не быть не только хорошей архитектурой веб-приложения, но и являться bad practice.
В последнее время мне довольно часто приходится разрабатывать простые веб-сайты на основе стека технологий .NET Framework. Конечно, я использую для этого ASP.NET MVC фреймворк, как де-факто стандарт на сегодняшний день.
А вот на уровне Данных уже возможны варианты: существует довольно много вполне нормальных по качеству ORM, а поэтому возможен выбор. Я обычно выбираю либо Entity framework — продукт microsoft, либо NHibernate — порт популярной Java ORM. Ещё есть хорошая ORM — DataObjects.Net, но это платное энтерпрайз решение, которое вряд ли подходит для простых сайтов.
Из СУБД я использую обычно MsSQL, как нативную для MS. Хотя, наверное, данные ORM позволят вам использовать и какие-нибудь MySQL и PostgreSQL.
Теперь возникает вопрос, что дальше делать? В принципе, данные из БД мы уже можем легко достать, да и CRUD имплементирован. Пока я являюсь сторонником N-layer architecture. В связи с этим, буду обсуждать архитектуру приложения на основе трёхзвенной архитектуры.
В любом простом приложении, по моему мнению, должны быть такие слои, как Отображение (Presentation layer) — это стандартный ASP.NET MVC проект. Он должен получать запросы от клиентов в контроллерах, запрашивать данные у сервисов, и отдавать их клиентам.
Слой бизнес логики — это Domain. Тут, лично я, создаю бизнес-сущности, а-ля:
[sourcecode language=»php»]
public class UserPhoto {
public virtual long Id
{
get;
set;
}
public virtual string Link
{
get;
set;
}
public virtual User User
{
get;
set;
}
}
[/sourcecode]
Кроме того, в Domain я создаю интерфейсы сервисов — источников данных. Например,
[sourcecode language=»php»]
///
public interface IRoleService
{
Role GetRoleByName(string name);
}
[/sourcecode]
Конечно же, будет замечательно, если вы в Domain опишите все ограничения на данные.
Третий слой в проекте — это инфраструктура. Тут необходимо реализовывать репозитории всех бизнес-сущностей. Данный слой сильно зависит от того, какую ORM вы используете.
Каждый слой я выделяю в отдельный проект. Также я создаю проект Services — его задача — это реализация всех интерфейсов, описанных в Domain. Затем, DI-контейнер разрешит нужные мне интерфейсы, используя данные имплементации.
Собственно, слова для программиста — это воздух. Поэтому, я предлагаю вам посмотреть на Best practices. Если вы используете NHibernate, то стоит серьезно изучить замечательный низкоуровневый фреймворк S#arp Architecture. Он аккумулирует в себе всё самое хорошее, и показывает, как нужно разрабатывать маленькие и средние по объему приложения.
Данный фреймворк, к сожалению, давно не обновляется. Поэтому, по умолчанию там ASP.NET MVC 3. Однако добрые люди обновили все зависимости (в том числе и ASP.NET до MVC 5) и выложили это дело на гитхаб.
Если ваш выбор — это Entity framework, то готового фреймворка, к сожалению, нет (по крайне мере я его не знаю). Однако есть крайне интересный проект SocialGoal на гитхабе — бесплатная небольшая социальная сеть, в котором как раз таки реализованы все те вещи, о которых я говорил. Думаю, тот проект можно брать, как основу.
Кстати, этот проект построен на всём самом современном: ASP.NET MVC 5, EF 6 Code First, AutoMapper, Autofac и TDD. Поэтому, данный репозиторий отлично подойдёт для обучения.
Ещё одно примечание. SocialGoal построен на основе http://efmvc.codeplex.com/ — можно посмотреть и в эту сторону.
Буду рад, если вы напишите свои архитектурные решения для простых сайтов на ASP.NET MVC в комментариях.
Категории: Веб-мастеринг Программирование
Метки: .NET, программирование