Переход от однопользовательских настольных приложений к многопользовательской разработке

Question

Я пытаюсь загрузить микро-ISV по ночам и выходным. У меня есть приложение на очень ранней стадии разработки. Он написан на C# и состоит в основном из коллекции классов, представляющих проблемную область. На данный момент нет интерфейса или сохранности данных. (Я даже не остановился на платформе.NET. Это достаточно рано, чтобы я мог перейти на Java или собственные исполняемые файлы)

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

Многопользовательская часть - это то место, где у меня нет опыта. Я знаю, что каждому пользователю понадобятся две вещи:

• IP-связь с удаленным сервером в общедоступном Интернете

• Аутентификация пользователя и удаленное хранение данных

У меня есть представление о том, какие услуги я хочу предоставить этому серверу (поиск информации и транзакции от пользователя к пользователю), но помимо этого я не в себе. Сервер должен быть размещен третьей стороной, поскольку у меня нет ресурсов для запуска собственного сервера. Помня, что я буду единственным разработчиком этого проекта в обозримом будущем:

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

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

Answer 1

Что касается перехода к многопользовательскому приложению, централизация ваших данных, конечно же, является первым шагом, и самый простой способ достичь этого - часто использовать облачную базу данных, такую ​​как Amazon SimpleDB или MS Azure. Обычно вы получаете ключ доступа и длинный "секрет" для аутентификации.

Если ваши данные не очень реляционные, вы можете рассмотреть Amazon SimpleDB. Существуют SDK для большинства языков, которые позволяют простому коду сохранять / извлекать данные в вашей базе данных SimpleDB, используя ключ и секрет, в любой точке мира. Вы платите за услугу, основываясь на вашем хранилище данных и объеме трафика, поэтому у нее очень низкий барьер входа, особенно во время разработки. Он также будет масштабироваться от крошечного домашнего приложения до размера, равного amazon.com.

Если вы решили реализовать свой собственный сервер базы данных, вы должны помнить две ключевые вещи:

1. Убедитесь, что состояние сеанса не существует, т. Е. Клиент выполняет вызов вашей веб-службы, происходит какое-то действие, и сервер забывает об этом клиенте (кроме любых измененных данных в базе данных, разумеется). Точно так же клиент не должен хранить какие-либо данные локально, которые могут измениться в результате взаимодействия с другим пользователем. Кэшируйте только локально данные, которые вы знаете, не изменится (или что вам все равно, если они изменятся).
2. Для веб-службы каждый вызов обычно обрабатывается в отдельном потоке, поэтому необходимо обеспечить безопасный доступ к базе данных из нескольких потоков. Если вы используете стандартные.NET или Java способы общения с базой данных SQL, это должно быть выполнено за вас. Однако, если вы реализуете свое собственное хранилище данных, вам нужно о чем-то беспокоиться.

Что касается вопроса REST/SOAP и т. Д., То ключевым моментом должно быть решение о том, какие платформы / устройства вы хотите использовать для подключения к серверу базы данных. Например, если вы внедрили свой сервер в.NET, вы могли бы рассмотреть WCF для реализации ваших веб-сервисов. Однако это может создать трудности, если позже вы захотите использовать не-.NET клиенты. SOAP является зрелой технологией для веб-сервисов, но довольно обременительной для реализации, и библиотеки для завершения обработки вызовов SOAP могут быть необязательно доступны для данной клиентской платформы. REST прост в реализации (тривиально легко, если вы используете ASP.NET MVC на своем сервере), доступен любому клиенту, который может обрабатывать HTTP POST/GET без необходимости в библиотеках, и прост в тестировании, поэтому REST будет моей технологией выбора,

Answer 2

Если вы придерживаетесь.net (мои личные предпочтения), я бы выставлял вызовы доступа к данным через WCF. Конфигурация WCF действительно гибкая, и ее довольно легко подобрать, и вы захотите спрятать свою БД за уровнем обслуживания.

Answer 3

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

2.none