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

Question

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

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

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

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

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

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

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

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

Answer 1

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

2.none

Answer 2

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

Answer 3

Что касается перехода на многопользовательское приложение, то, конечно, централизовать ваши данные - это, конечно, первый шаг, и самый простой способ добиться этого - часто использовать облачную базу данных, такую ​​как 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 будет моей технологией выбора ,