Создание обширного проекта для продажи

Question

Я собираюсь начать проект C # с нуля, который будет состоять из нескольких модулей, поэтому он может быть продан модулями существующего приложения PHP / ASP / MySQL / Oracle / MS SQL, которое удается показать 3D-объекты и создание 2D- и 3D-файлов САПР из веб-приложения, которое пользователь может использовать для создания всего этого.

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

• какие классы я должен сделать доступными для переопределения клиентом, чтобы я мог обеспечить расширяемость в наших модулях?
• какой «пакет» я должен использовать, чтобы «продать»? DLL, CAB, MSI?
• я должен использовать SubSonic / NHibernate, чтобы пользователь мог создать свой собственный DAL? Наша прототипная реализация будет использовать только Oracle.

Я сейчас немного растерян, я знаю, что делать, но не знаю, как мне этого добиться (имея в виду этот идеальный путь кодирования).

Любые хорошие идеи программирования приветствуются :))

Answer 1

Для быстрого ответа на каждый из ваших явных вопросов я бы сказал.

Что касается интеграции, изучите инверсию принципов управления и то, как она используется в целях расширения. Следите за MEF, Microsoft Extensibility Framework. Что касается того, что, ваши точки интеграции будут зависеть в основном от типа приложения, которое вы пишете, и вашей целевой аудитории. Это также зависит от того, какой контроль вы хотите передать третьим лицам. Например, у Reflector имеется отличная, почти широко открытая структура плагинов.

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

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

Answer 2

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

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

Answer 3

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

Answer 4

Прежде всего, подумайте, КАК расширяемый это должно быть. Если вы просто предоставляете полную расширяемость, вы рискуете потерять безопасность и нестабильность. Вы можете разрешить переопределение классов, просто убедитесь, что вы помечаете только правильные методы как «виртуальные». Тип пакета для продажи зависит от вашей целевой аудитории. Если вы нацелены на опытных пользователей, то библиотеки DLL должны быть в порядке. Но если вам нужна простая в использовании система, тогда MSI или любой другой установщик будет мудрее.

Что касается DAL, вам действительно следует проанализировать преимущества и недостатки каждого из них и выбрать тот, который подходит.

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

Answer 5

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

Когда-нибудь слышали о том, как Ebay начал? Долгое время они были очень успешными, но имели действительно плохой код C ++ (и кто знает, что еще).

Answer 6

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