Quais são algumas coisas para considerar ao desenvolver um aplicativo baseado na web para serem vendidos [fechado]

Question

Estou desenvolvendo um aplicativo para um cliente interno. Um dos requisitos é que seja desenvolvido de maneira tal que poderia potencialmente ser vendido a outras organizações. O aplicativo é um aplicativo de rastreamento para uma organização de angariação de fundos que irá gerir as suas doações, doadores, participantes e eventos. Eu já sei que vou precisar para desenvolver uma arquitetura de plug-in para autenticação (autorização será tratado internamente) e dados demográficos derivam de um diretório externo.

A aplicação será construída em ASP.NET/C#/Linq/SQL Server. Neste momento eu realmente não estou aberto a apoiar bancos de dados alternativas, mas eu estou pensando que eu poderia fazer isso no futuro através de diferentes drivers de Linq, se necessário.

Todas as aplicações web que eu construí até à data foram implementações personalizadas para que eu gostaria de saber se há outras coisas que eu preciso para o endereço através de plugins e / ou itens de configuração. Qualquer entrada seria útil.

Graças.

Answer 1

Quero adverti-lo contra a tentativa de tornar o quadro "fazer tudo". Este é um erro comum que muitos desenvolvedores fazer ao tentar construir seus primeiros aplicativos de software de mercado de massa.

Você tem um cliente já, e eles provavelmente estão financiando a versão inicial do aplicativo. Você precisa entregar como muito do que este necessidades dos clientes tão rápido quanto você pode ou falhar antes mesmo de começar a pensar sobre o mercado de massa.

Faça um favor e esperamos que este é o único cliente que nunca vai usar ou comprar o aplicativo. Projete sua aplicação praticamente exatamente o mesmo que você teria concebido qualquer um dos seus outros aplicativos personalizados no passado.

Tudo que você precisa fazer, a fim de escalá-lo para outros clientes mais tarde é manter as características da ASP.NET e funcionalidade, tanto quanto possível, mantê-lo tão simples e magra quanto possível, e corte como muitos "avançado "características da versão 1.x, como você pode se safar.

1.x será o seu campo de provas. Certifique-se de entregar um aplicativo que faz o que seu cliente inicial precisa dele para fazer e que ele faz isso muito bem.

Se você for bem sucedido, e 1.x faz realmente atender à maioria das exigências do seu cliente inicial, então você vai saber que você também tem um aplicativo que irá atender a maioria das necessidades de qualquer um dos seus clientes. Parabéns, você já está a maior parte do caminho para ter uma aplicação no mercado comercial viável!

As coisas que atente para:

1. Você realmente precisa para suportar múltiplas plataformas de banco de dados? Claro, você pode ter "alguns" clientes que poderiam "preferem" MySQL para SQL Server. Você será tentado a tentar escrever alguns DAL mágica que pode suportar Oracle, MySQL, VistaDB, SQL Server, etc. apenas mudando algumas opções de configuração ou fazer a escolha certa em um instalador. Mas o fato é que esse tipo de neutralidade "plataforma", acrescenta enorme complexidade ao seu design e impõe severas limitações sobre quais recursos você aproveitar. Coisas como o padrão de design provedor pode enganar em pensar que este tipo de projeto não é tão difícil ... mas que seria errado. Ser pragmático e projetar seu aplicativo para que ele seja aceitável para 90% de seu mercado potencial. Com acesso a dados em particular é geralmente seguro dizer que 90% ou mais do mercado dispostos a instalar e executar uma aplicação ASP.NET também são capazes e dispostos a usar SQLExpress ou SQL Server. Na maioria dos casos você vai economizar muito mais dinheiro e tempo, projetando para o servidor SQL apenas do que você nunca vai fazer em vendas adicionais de apoio a vários bancos de dados.

2. Tente evitar fazer "tudo" configurável através de ferramentas de administração on-line. Por exemplo, você será tentado a ter todo o texto no configurável aplicação de ferramentas de administração. Isso é ótimo, mas também é caro. Leva mais tempo para se desenvolver, requer que você aumentar o escopo de seu aplicativo para incluir uma bagunça inteira de ferramentas de administração que você não teria de outra forma necessária, e isso torna a aplicação mais complexa e difícil de usar para os 90% de seus clientes que não se importa o texto padrão.

3. Considere cuidadosamente localização. Se você não acha que vai ter uma grande vara mercado internacional para um idioma. A localização não é muito difícil, mas faz complicar cada aspecto de seu código um pouco ... e isso acrescenta-se a um monte em qualquer aplicação de qualquer tamanho em tudo. Minha regra de ouro é alvo apenas a linguagem do meu mercado inicial. Se o aplicativo tem interesse em outros mercados, então eu voltar e fazer localização em versão 2.x depois de eu recuperar algum dinheiro a partir da versão 1.0 e provar o aplicativo tem um mercado viável, em primeiro lugar. Mas se você sabe que vai estar em mais de uma língua ou cultura, localização apoio desde o início.

4. Para a versão 1.0, não se preocupe muito com drop-in módulos ou APIs de serviços de fantasia. Se você Already tinha muita experiência em frameworks reutilizáveis ??você seria capaz de ter este material na versão 1.0, mas se você não tem experiência neste tipo de arquiteturas você só vai perder muito tempo com essas características em versão 1.x e você provavelmente vai ainda obtê-lo errado e tem que re-arquiteto na versão 2.x de qualquer maneira.

5. Verifique se o aplicativo tem realmente boas reportagens. Para o tipo de aplicação que você está falando, este será o que decide se o aplicativo ainda tem um mercado em tudo. Você precisa de relatórios bonitas que não só são classificáveis ??/ filtrável na tela, mas também são imprimíveis. Colocar o seu dinheiro e tempo para este fora do portão.

Answer 2

A coisa mais importante é para projetá-lo de tal maneira a que é completamente genérico ou seja, não há nenhuma informação específica cliente codificado ou incorporado.

Qualquer coisa específica do cliente deve ser configurável através de meta-dados. Como fazer isso é completamente até você, mas as principais formas são através de XML, banco de dados ou arquivos de propriedades.

Se você projetá-lo desta forma ele poderia estar no vendida para qualquer número de clientes que terão cada um de seus próprios arquivos de configuração ou de dados.

Answer 3

Abarax deu uma grande resposta, eu enfatizar que você deve considerar Localização - tanto para línguas faladas (Inglês, francês, alemão, etc) e linguagem da Organização exemplo alguns lugares podem chamá-lo de um quadro de horários, Docket ou ordem de trabalho, e cada um vai lamentar e lamentar e lamentar se tudo não corresponder-se com o que sempre chamado algo.

Answer 4

Se você estiver usando tecnologias de código aberto, passar um pouco de tempo mantendo todas as informações de licença em um só lugar.