Какие общие вещи следует учитывать при разработке веб-приложения для продажи [закрыто]

Question

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

Приложение будет построено на ASP.NET/C#/Linq/SQL Server.На данный момент я не совсем готов поддерживать альтернативные базы данных, но думаю, что смогу сделать это в будущем с помощью других драйверов Linq, если это необходимо.

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

Спасибо.

Answer 1

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

У вас уже есть клиент, и он, скорее всего, финансирует первоначальную версию приложения.Вам нужно как можно быстрее доставить как можно больше того, что нужно этому клиенту, иначе это потерпит неудачу, прежде чем вы даже начнете думать о массовом рынке.

Сделайте себе одолжение и ожидайте, что это единственный клиент, который КОГДА-ЛИБО будет использовать или покупать приложение.Создавайте свое приложение практически так же, как вы проектировали любое другое пользовательское приложение в прошлом.

Все, что вам нужно сделать, чтобы впоследствии масштабировать его для других клиентов, — это максимально придерживаться стандартных функций и функций asp.net, делать его максимально простым и экономичным и исключить из него как можно больше «расширенных» функций. версию 1.x, как вам может сойти с рук.

1.x станет вашим испытательным полигоном.Убедитесь, что вы предоставляете приложение, которое делает то, что нужно вашему первоначальному клиенту, и делает это очень хорошо.

Если вы добились успеха и версия 1.x действительно соответствует большинству первоначальных требований вашего клиента, вы будете знать, что у вас также есть приложение, которое удовлетворит большую часть потребностей любого из ваших клиентов.Поздравляем, вы уже прошли большую часть пути к созданию жизнеспособного коммерческого приложения!

На что следует обратить внимание:

1. Вам действительно нужна поддержка нескольких платформ баз данных?Конечно, у вас могут быть «некоторые» клиенты, которые «предпочитают» MySql SQL Server.У вас возникнет соблазн попробовать написать какой-нибудь волшебный DAL, который сможет поддерживать Oracle, MySQL, VistaDB, SQL Server и т. д.просто изменив некоторые параметры конфигурации или сделав правильный выбор в установщике.Но дело в том, что такая «платформенная» нейтральность значительно усложняет ваш дизайн и накладывает серьезные ограничения на то, какими функциями вы можете воспользоваться.Такие вещи, как шаблон проектирования провайдера, могут ввести вас в заблуждение, заставив думать, что этот тип проектирования не так уж и сложен...но вы ошибаетесь.Будьте прагматичны и спроектируйте свое приложение так, чтобы оно было приемлемо для 90% вашего потенциального рынка.В частности, в отношении доступа к данным можно с уверенностью сказать, что 90% или более участников рынка, желающих установить и запустить приложение ASP.NET, также способны и хотят использовать SQLExpress или SQL Server.В большинстве случаев вы сэкономите гораздо больше денег и времени, проектируя только для SQL-сервера, чем когда-либо заработаете на дополнительных продажах от поддержки нескольких баз данных.

2. Старайтесь не делать «все» настраиваемым с помощью онлайн-инструментов администрирования.Например, у вас возникнет соблазн настроить ВЕСЬ текст в приложении с помощью инструментов администратора.Это здорово, но это также дорого.Разработка занимает больше времени, требует расширения объема вашего приложения, чтобы включить в него целый набор инструментов администрирования, которые в противном случае вам не понадобились бы, и это делает приложение более сложным и трудным для использования 90% ваших клиентов. это не против текста по умолчанию.

3. Тщательно продумайте локализацию.Если вы не думаете, что у вас появится большой международный рынок, придерживайтесь одного языка.Локализация не слишком сложна, но она немного усложняет каждый аспект вашего кода...и это очень много значит для любого приложения любого размера.Мое практическое правило — ориентироваться только на язык моего первоначального рынка.Если приложение проявляет интерес к другим рынкам, я возвращаюсь и выполняю локализацию в версии 2.x после того, как получу немного денег от версии 1.0 и докажу, что приложение вообще имеет жизнеспособный рынок.Но если вы знаете, что будете принадлежать более чем к одному языку или культуре, поддержите локализацию с самого начала.

4. В версии 1.0 не беспокойтесь слишком сильно о дополнительных модулях или необычных API-интерфейсах служб.Если у вас уже есть большой опыт работы с повторно используемыми фреймворками, вы сможете использовать все это в версии 1.0, но если у вас нет опыта работы с такого рода архитектурами, вы просто потратите слишком много времени на эти функции в версии 1.x, и вы скорее всего, все равно ошибется, и ему все равно придется перепроектировать версию 2.x.

5. Убедитесь, что приложение имеет ДЕЙСТВИТЕЛЬНО хорошие отчеты.Для того типа приложения, о котором вы говорите, именно это будет определять, будет ли у приложения вообще рынок.Вам нужны красивые отчеты, которые можно не только сортировать и фильтровать на экране, но и можно распечатать.Вложите в это свои деньги и время.

Answer 2

Самое главное — спроектировать его таким образом, чтобы он был полностью универсальным, т.е.нет никакой информации, специфичной для клиента, жестко закодированной или встроенной.

Все, что специфично для клиента, должно быть настроено с помощью метаданных.Как вы это сделаете, полностью зависит от вас, но основные способы — через XML, базу данных или файлы свойств.

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

Answer 3

Абаракс дал отличный ответ, я бы подчеркнул, что вам следует рассмотреть вопрос о локализации - как для разговорных языков (английский, французский, немецкий и т. д.), так и для языка Организации, например.в некоторых местах это может называться «Табель учета рабочего времени», «Дежурная книжка» или «Наряд на работу», и каждый будет ныть, ныть и ныть, если все не соответствует тому, как они всегда что-то называли.

Answer 4

Если вы используете технологии с открытым исходным кодом, потратьте немного времени на хранение всей информации о лицензиях в одном месте.