Определение количества уровней в многоуровневом приложении

Question

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

СлоиВаша типичная презентация, бизнес, данные.Об уровне данных заботится сервер базы данных.Бизнес-уровень будет содержать компонент DAL для доступа к серверу базы данных по протоколу TCP.Я должен разделить эти уровни на уровни:

1. Уровни представления и бизнес-уровни можно сохранить на одном уровне.

2. Уровень представления данных на отдельном уровне сам по себе, а бизнес-уровень - на отдельном уровне.

В случае выбора 2 доступ к бизнес-уровню будет осуществляться с помощью уровня представления с использованиемслужба WCF по протоколу http или tcp.

Я не вижу какой-либо тяжелой обработки на бизнес-уровне, поэтому склоняюсь к варианту 1 выше.Я также чувствую по той же причине, что добавление нового уровня приведет только к задержке в сети.Тем не менее, с точки зрения масштабируемости в случае, если мне нужно увеличить или уменьшить масштаб, какой путь лучше?Это приложение должно поддерживать до 6 миллионов пользователей в час.В каждом сеансе пользователя будет разумное количество данных, в которых будут храниться настройки пользователя и другие детали.Я также буду использовать кэширование на уровне страниц ..

Спасибо за ваше время ...

Answer 1

Мне действительно не нравится термин «n-уровневая архитектура», когда речь идет о простых веб-приложениях CRUD.Выберите шаблон дизайна, такой как MVC, и сделайте это.Забудьте об уровнях полностью.

Ваше приложение не будет достаточно большим или популярным, чтобы беспокоиться о масштабировании отдельных компонентов по отдельности.По всей вероятности, ваше приложение будет одним решением VS (и, возможно, даже одним приложением в рамках проекта).Если что-то из того, что я сказал, кажется незначительным, прошу прощения, но я считаю почти все, что я построил, в одном ведре.Кроме того, если что-то, что я сказал, совершенно неверно в вашем конкретном проекте, я снова извиняюсь и смиренно принимаю отрицательные отзывы.Это действительно звучит так, как будто ты слишком много думаешь об этом.Создайте его и посмотрите.

Вы создаете веб-сайт с вводом, отображением и доступом к данным.Запустите новое решение ASP.NET MVC и отправляйтесь в город.