2008-10-10 2 views
13

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

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

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

Спасибо.

+0

Мне просто интересно, что же случилось с вашим приложением и с вашим подходом. Было бы неплохо, если бы вы рассказали о своем опыте. – user347594 2010-06-26 17:13:21

ответ

27

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

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

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

Все, что вам нужно сделать для того, чтобы увеличить его для других клиентов, - это как можно больше использовать функции и функции 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. Убедитесь, что приложение имеет ДЕЙСТВИТЕЛЬНО хорошую отчетность. Для такого приложения, о котором вы говорите, это будет то, что решает, имеет ли приложение даже рынок вообще. Вам нужны красивые отчеты, которые не только сортируются/фильтруются на экране, но также доступны для печати. Положите ваши деньги и время в это из ворот.

4

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

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

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

2

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

2

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

Смежные вопросы