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

Question

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

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

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

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

Answer 1

1. Для масштабируемости помогает отделить внутренний код от внешнего кода.Таким образом, если вы поместите код пользовательского интерфейса в проект MVC и столько кода обработки, сколько возможно, в один или несколько отдельных проектов WCF и бизнес-логики, не только ваш код будет более четким, но вы также сможете масштабировать уровни / уровни независимо от каждого из них.прочее.

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

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

РЕДАКТИРОВАТЬ для ответаВаши дополнительные вопросы:

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

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

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