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

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

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

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

Спасибо.

Ответ 1

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

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

Сделайте себе одолжение и ожидайте, что это единственный клиент, который будет использовать или покупать приложение. Создайте приложение практически точно так же, как и в прошлом.

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

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

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

Остерегайтесь:

Вам действительно нужно поддерживать несколько платформ баз данных? Конечно, у вас могут быть "некоторые" клиенты, которые могут "предпочесть" MySql на SQL Server. У вас возникнет соблазн попытаться написать магический DAL, который может поддерживать Oracle, MySQL, VistaDB, SQL Server и т.д., Просто изменив некоторые параметры конфигурации или сделав правильный выбор в установщике. Но факт в том, что такой "нейтральный" "платформа" добавляет огромную сложность вашему дизайну и налагает серьезные ограничения на то, какие функции вы используете. Такие вещи, как шаблон проектирования поставщика, могут обмануть вас в мысли, что такой дизайн не так уж ист... но вы ошибаетесь. Будьте прагматичны и разрабатывайте свое приложение, чтобы оно было приемлемым для 90% вашего потенциального рынка. С доступом к данным, в частности, можно с уверенностью сказать, что 90% или более компаний, желающих установить и запустить приложение ASP.NET, также могут и хотят использовать SQLExpress или SQL Server. В большинстве случаев вы сэкономите гораздо больше денег и времени, разработав только SQL-сервер, чем когда-либо сделаете в дополнительных продажах поддержку нескольких баз данных.
Старайтесь избегать настройки "все" с помощью инструментов онлайн-администрирования. Например, у вас возникнет соблазн иметь ВСЕ текст в приложении, настраиваемый с помощью инструментов администратора. Это здорово, но это тоже дорого. Требуется больше времени для разработки, требует, чтобы вы увеличили объем своего приложения, включив в него целый беспорядок, который вам не нужен в противном случае, и это делает приложение более сложным и трудным для использования для 90% ваших клиентов которые не возражают против текста по умолчанию.
Внимательно изучите локализацию. Если вы не думаете, что у вас будет большой международный рынок, придерживайтесь одного языка. Локализация не слишком сложна, но она немного усложняет каждый аспект вашего кода... и это добавляет много общего в любом приложении любого размера. Мое эмпирическое правило нацелено только на язык моего первоначального рынка. Если у приложения интерес к другим рынкам, я вернусь и сделаю локализацию в версии 2.x после того, как я окупирую некоторые деньги из версии 1.0 и докажу, что приложение имеет жизнеспособный рынок в первую очередь. Но если вы знаете, что находитесь на более чем одном языке или культуре, поддержите локализацию с самого начала.
Для версии 1.0 не беспокойтесь слишком много о выпадающих модулях или интерфейсах API. Если у вас уже есть много опыта в многоразовых фреймворках, вы сможете получить этот материал в версии 1.0, но если вам не хватает опыта в таких архитектурах, вы просто потратите слишком много времени на эти функции в версии 1.x, и вы скорее всего, все равно ошибается, и в любом случае придется перепроектировать в версии 2.x.
Убедитесь, что приложение имеет ДЕЙСТВИТЕЛЬНО хорошую отчетность. Для такого приложения, о котором вы говорите, это будет то, что решает, имеет ли приложение даже рынок вообще. Вам нужны красивые отчеты, которые не только сортируются/фильтруются на экране, но также доступны для печати. Положите ваши деньги и время в это из ворот.

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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