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

Question

Я хотел бы создать приложение ASP.NET, которое позволяет пользователям отслеживать различные сообщения из разных каналов (например, сообщения в Twitter, в которых появляются названия конкретных продуктов / компаний и т. Д., Сообщения со страницы Facebook). Эти сообщения будут собираться и обрабатываться службой.

Каков рекомендуемый путь к этому? Моя первоначальная идея - создать сервис, который собирает и обрабатывает необходимую информацию и сохраняет ее в базе данных (такой же, как та, которую использует приложение asp.net). Таким образом, когда пользователь проверяет веб-приложение, он или она может видеть новые сообщения, прочитанные из общей базы данных.

Я не уверен, что это правильный способ сделать это. Должны ли компоненты работать в одной базе данных? Если нет, то как приложение asp.net должно прочитать необходимые данные?

Answer 1

Почему они не должны использовать одну и ту же базу данных? В конце концов, они пишут / читают одни и те же данные, а базы данных предназначены для того, чтобы быть центральными хранилищами для нескольких приложений. Вы не хотели бы иметь более одной системы записи для ваших данных. Две системы записи по существу означают отсутствие системы записи.

Решение, которое вы предлагаете, звучит хорошо для меня:

1. Служба (служба Windows, запланированное консольное приложение и т. Д.) Регулярно запускается для очистки данных из внешних ресурсов, преобразования этих данных в модель вашего домена и сохранения в локальной базе данных.
2. Веб-сайт считывает данные из этой базы данных и предоставляет отчеты для пользователей.

Имейте в виду, что такие сервисы, как Facebook и Twitter, также предоставляют API и различные «виджеты», которые предназначены для встраивания непосредственно в веб-страницу. Идея состоит в том, что пользователь на вашем сайте сможет видеть данные из Twitter / Facebook / и т. Д. без вашего серверного кода когда-либо делать что-либо с ним или знать что-либо об этом. Разве это не отвечает вашим потребностям? Или вам действительно нужно очищать / преобразовывать / хранить данные локально?

Answer 2

Абсолютно хорошо для чтения и записи отдельных приложений в одну и ту же базу данных назначения.То, что вы предложили, прекрасно.

Чтобы уберечься от репликации кода, вы можете / должны написать одну библиотеку доступа к данным для чтения / записи в БД, и тогда оба ваших приложения будут использовать ее.Если вы не хотите, чтобы вас связывали с реализацией базы данных, пусть код ваших приложений будет зависеть от интерфейсов доступа к данным, чтобы они не знали о методе персистентности.

Answer 3

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

Оранжевые фоновые компоненты означают услуги.Приложение ASP.NET MVC связывается со службой потоковой передачи (которая открывает потоки для каждой учетной записи пользователя в Twitter) посредством вызовов веб-службы.Служба WCF - это служба единого экземпляра, которая управляет этими потоками.

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

Требуется подмножество слоя BL, поскольку для новых твитов или электронных писем необходимо классифицировать их по некоторым правилам.Этот слой и слой домена находятся в отдельных сборках, совместно используемых службами и веб-приложением.