Архитектура приложения ASP.NET MVC

Я занимаюсь анализом потенциально большого веб-сайта, и у меня есть ряд вопросов.

Веб-сайт будет написан в ASP.NET MVC 3 с движком просмотра бритвы. В большинстве случаев я обнаружил, что контроллеры напрямую используют базовую базу данных (используя шаблон домена/репозитория), поэтому между ними нет службы WCF. Мой первый вопрос: эта архитектура подходит для большого сайта с большим количеством трафика? Всегда можно загрузить баланс сайта, но это хороший подход? Или я должен заставить сайт использовать службы WCF, которые взаимодействуют с данными?

Вопрос 2: Я хотел бы принять принципы CQS, а это значит, что я хочу отделить запрос от команды. Таким образом, это означает, что часть запроса будет иметь другую модель (оптимизированную для представлений), чем командную часть (оптимизированную для бизнес-целей и содержащую только свойства, необходимые для завершения команды), но оба действуют в одной базе данных. Считаете ли вы, что это хорошая идея?

Спасибо за совет!

Ответ 1

Для масштабируемости это позволяет отделить внутренний код от внешнего кода. Поэтому, если вы поместите код пользовательского интерфейса в проект MVC и как можно больше кода обработки в один или несколько отдельных проектов WCF и бизнес-логики, не только ваш код станет более четким, но вы также сможете масштабировать уровни/уровни независимо от каждого другие.
CQRS отлично подходит для сайтов с высоким трафиком. Я думаю, что CQRS, должным образом объединенный с хорошей базовой библиотекой для DDD, хорош даже для сайтов с низким трафиком, потому что это упрощает реализацию бизнес-логики. Разделение данных на оптимизированную по чтению модель и оптимизированную для записи модель имеет смысл с архитектурной точки зрения также потому, что она делает изменения более удобными (возможно, еще немного работы, но определенно легче вносить изменения, не нарушая что-то).

Однако, если оба действуют в одной и той же базе данных, я бы удостоверился, что прочитанная модель полностью состоит из представлений, чтобы вы могли модифицировать объекты по мере необходимости, не нарушая код чтения. Это имеет то преимущество, что вам нужно будет писать меньше кода, но ваша модель записи по-прежнему будет состоять из полноценной модели сущностей, а не только для хранилища событий.

ИЗМЕНИТЬ, чтобы ответить на дополнительные вопросы:

Что мне нравится делать, это использовать службу данных WCF для модели Read. Эта технология (специфичная для .NET 4.0) создает веб-службу OData (= REST + Atom с поддержкой LINQ) поверх модели данных, например Entity Framework EDMX.

Итак, я создаю модель Read в SQL Server (Views), а затем создаю из нее модель Entity Framework, а затем создаю службу данных WCF поверх этого в режиме только для чтения. Это звучит намного сложнее, чем это, это занимает всего несколько минут. Вам не нужно создавать еще одну модель, просто покажите EDMX как доступную только для чтения. См. Также http://msdn.microsoft.com/en-us/library/cc668794.aspx.

Служба команд - это просто односторонняя регулярная служба WCF, служба Read - это служба данных WCF, и ваше приложение MVC потребляет их обоих.