Quels sont les points communs à prendre en compte lors du développement d’une application Web à vendre? [Fermé]

Question

Je développe une application pour un client interne. L’une des exigences est qu’il soit développé de manière à pouvoir éventuellement être vendu à d’autres organisations. L'application est une application de suivi pour une organisation de collecte de fonds qui gérera leurs dons, donateurs, participants et événements. Je sais déjà que je devrai développer une architecture de plug-in pour l'authentification (l'autorisation sera gérée en interne) et dériver les données démographiques d'un répertoire externe.

L'application sera créée sur ASP.NET/C#/Linq/SQL Server. À ce stade, je ne suis pas vraiment disposé à prendre en charge des bases de données alternatives, mais je pense que je pourrais le faire à l'avenir via différents pilotes Linq, si nécessaire.

Toutes les applications Web que j'ai construites jusqu'à présent sont des implémentations personnalisées. J'aimerais donc savoir s'il y a d'autres points que je dois aborder via des plugins et / ou des éléments de configuration. Toute entrée serait utile.

Merci.

Answer 1

Je tiens à vous mettre en garde contre toute tentative visant à forcer le "tout faire". cadre. Il s'agit d'une erreur courante commise par de nombreux développeurs lors de la création de leurs premières applications logicielles grand public.

Vous avez déjà un client et ceux-ci financent probablement la version initiale de l'application. Vous devez fournir au maximum les besoins de ce client le plus rapidement possible ou sans succès, avant même que vous ne pensiez au marché de masse.

Faites-vous une faveur et attendez-vous à ce que ce soit le seul client qui utilisera ou achètera JAMAIS l'application. Concevez votre application à peu près exactement de la même façon que vous auriez conçu l'une de vos autres applications personnalisées dans le passé.

Pour pouvoir le proposer ultérieurement à d'autres clients, il vous suffit de vous en tenir au maximum aux fonctionnalités asp.net de base, de le garder aussi simple et svelte que possible et de couper le plus grand nombre possible de " avancé " caractéristiques de la version 1.x que vous pouvez vous en sortir.

1.x sera votre terrain d’essai. Assurez-vous de livrer une application qui répond aux besoins de votre client initial et qui le fait extrêmement bien.

Si vous réussissez et que 1.x répond effectivement à la plupart des besoins de votre client initial, vous saurez que vous disposez également d'une application qui répondra à la plupart des besoins de l'un de vos clients. Félicitations, vous êtes déjà en bonne voie pour avoir une application viable sur le marché commercial!

À surveiller:

1. Avez-vous vraiment besoin de supporter plusieurs plates-formes de bases de données? Bien sûr, vous pourriez avoir "certains" les clients qui pourraient "préférer" MySql à SQL Server. Vous serez tenté d'essayer d'écrire une DAL magique prenant en charge Oracle, MySQL, VistaDB, SQL Server, etc. simplement en modifiant certaines options de configuration ou en effectuant la sélection appropriée dans un programme d'installation. Mais le fait est que ce type de "plate-forme" La neutralité ajoute une complexité énorme à votre conception et impose de sévères limitations quant aux fonctionnalités que vous exploitez. Des éléments tels que le modèle de conception du fournisseur peuvent vous amener à penser que ce type de conception n'est pas si difficile… mais vous auriez tort. Soyez pragmatique et concevez votre application de manière à ce qu'elle soit acceptable pour 90% de votre marché potentiel. Avec l’accès aux données en particulier, on peut généralement affirmer que 90% ou plus du marché souhaitant installer et exécuter une application ASP.NET est également capable et désireux d’utiliser SQLExpress ou SQL Server. Dans la plupart des cas, vous économiserez beaucoup plus de temps et d'argent en concevant uniquement pour le serveur SQL que vous ne ferez jamais de ventes supplémentaires en prenant en charge plusieurs bases de données.

2. Essayez d’éviter de créer "tout". configurable via des outils d'administration en ligne. Par exemple, vous serez tenté de faire en sorte que TOUS les textes de l'application soient configurables à l'aide des outils d'administration. C'est génial, mais c'est aussi cher. Son développement prend plus de temps, il faut augmenter la portée de votre application pour y inclure tout un fouillis d'outils d'administration dont vous n'auriez pas besoin autrement, et cela rend l'application plus complexe et difficile à utiliser pour 90% de vos clients. cela ne dérange pas le texte par défaut.

3. Examinez attentivement la localisation. Si vous ne pensez pas que votre marché international sera important, tenez-vous-en à une seule langue. La localisation n’est pas difficile, mais elle complique un peu chaque aspect de votre code ... et cela s’ajoute à beaucoup dans toute application, quelle que soit sa taille. Ma règle empirique est de ne cibler que la langue de mon marché initial. Si l'application a un intérêt sur d'autres marchés, je retourne en arrière et je fais la localisation dans la version 2.x après avoir récupéré des liquidités de la version 1.0 et je prouve que l'application a un marché viable en premier lieu. Mais si vous savez que vous serez dans plus d'une langue ou d'une culture, prenez en charge la localisation dès le début.

4. Pour la version 1.0, ne vous inquiétez pas trop des modules sans rendez-vous ou des API de service sophistiquées. Si vous aviez déjà beaucoup d’expérience dans les frameworks réutilisables, vous pourriez avoir ce genre de choses dans la version 1.0, mais si vous manquez d’expérience dans ce type d’architecture, vous perdrez trop de temps avec ces fonctionnalités dans la version 1.x et vous-même. sera probablement toujours dans l'erreur et devra de nouveau architecturer dans la version 2.x.

5. Assurez-vous que l'application génère VRAIMENT de bons rapports. Pour le type d’application dont vous parlez, ce sera ce qui décidera si l’application a même un marché. Vous avez besoin de jolis rapports non seulement triables / filtrables à l'écran, mais également imprimables. Mettez votre argent et votre temps hors de cette porte.

Answer 2

Le plus important est de le concevoir de manière à ce qu’il soit complètement générique, c’est-à-dire qu’il n’existe aucune information propre au client, codée en dur ou intégrée.

Tout ce qui est spécifique au client doit être configurable via des méta-données. Vous pouvez le faire à votre guise, mais les principaux moyens sont XML, une base de données ou des fichiers de propriétés.

Si vous le concevez de cette façon, il pourrait être vendu à un nombre quelconque de clients qui auront chacun leurs propres fichiers de configuration ou données.

Answer 3

Abarax a donné une excellente réponse. Je tiens à souligner que vous devriez envisager la localisation - à la fois pour les langues parlées (anglais, français, allemand, etc.) et pour la langue de l’Organisation, par exemple. certains endroits peuvent appeler cela une feuille de temps, un dossier ou un ordre de travail, et chacun gémit et gémit et gémit si tout ne correspond pas à ce qu’ils ont toujours appelé quelque chose.

Answer 4

Si vous utilisez des technologies open source, passez un peu de temps à conserver toutes les informations de licence au même endroit.