Quali sono alcuni aspetti comuni da considerare quando si sviluppa un'applicazione basata sul Web da vendere [chiuso]

Question

Sto sviluppando un'applicazione per un cliente interno. Uno dei requisiti è che sia sviluppato in modo tale da poter essere potenzialmente venduto ad altre organizzazioni. L'applicazione è un'applicazione di tracciamento per un'organizzazione di raccolta fondi che gestirà le loro donazioni, donatori, partecipanti ed eventi. So già che dovrò sviluppare un'architettura plug-in per l'autenticazione (l'autorizzazione verrà gestita internamente) e derivare i dati demografici da una directory esterna.

L'applicazione sarà costruita su ASP.NET/C#/Linq/SQL Server. A questo punto non sono davvero aperto a supportare database alternativi, ma sto pensando di poterlo fare in futuro tramite diversi driver Linq, se necessario.

Tutte le applicazioni web che ho creato finora sono state implementazioni personalizzate, quindi vorrei sapere se ci sono altre cose che devo affrontare tramite plugin e / o elementi di configurazione. Qualsiasi input sarebbe utile.

Grazie.

Answer 1

Voglio metterti in guardia contro il tentativo di fare il " fare tutto " struttura. Questo è un errore comune che molti sviluppatori commettono quando provano a costruire le loro prime app software per il mercato di massa.

Hai già un cliente e probabilmente stanno finanziando la versione iniziale dell'applicazione. Devi fornire tutto ciò di cui questo cliente ha bisogno il più velocemente possibile o fallisce prima ancora di pensare al mercato di massa.

Fatevi un favore e aspettatevi che questo sia l'unico cliente che MAI utilizzerà o acquisterà l'applicazione. Progetta la tua applicazione più o meno esattamente come avresti progettato in passato una qualsiasi delle tue altre app personalizzate.

Tutto quello che devi fare per ridimensionarlo ad altri clienti in un secondo momento è attenersi al più possibile alle caratteristiche e alle funzionalità di asp.net di magazzino, mantenerlo il più semplice e snello possibile e tagliare il maggior numero di " advanced " caratteristiche dalla versione 1.x come puoi cavartela.

1.x sarà il tuo banco di prova. Assicurati di consegnare un'applicazione che fa ciò che il tuo cliente iniziale ha bisogno di fare e che lo fa estremamente bene.

Se hai successo e 1.x soddisfa effettivamente la maggior parte dei requisiti del tuo cliente iniziale, allora saprai di avere anche un'applicazione che soddisferà la maggior parte delle esigenze di tutti i tuoi clienti. Congratulazioni, sei già in gran parte pronto ad avere una valida applicazione per il mercato commerciale!

Cose a cui prestare attenzione:

1. Hai davvero bisogno di supportare più piattaforme di database? Certo, potresti avere " alcuni " clienti che potrebbero " preferire " MySql a SQL Server. Sarai tentato di provare a scrivere qualche DAL magico che possa supportare Oracle, MySQL, VistaDB, SQL Server, ecc. Semplicemente cambiando alcune opzioni di configurazione o facendo la scelta giusta in un programma di installazione. Ma il fatto è che questo tipo di "piattaforma" la neutralità aggiunge un'enorme complessità al tuo design e impone gravi limitazioni sulle funzionalità di cui usufruisci. Cose come il modello di progettazione del fornitore potrebbero indurti a pensare che questo tipo di progettazione non sia così difficile ... ma ti sbaglieresti. Sii pragmatico e progetta la tua applicazione in modo che sia accettabile per il 90% del tuo mercato potenziale. Con l'accesso ai dati in particolare è generalmente sicuro affermare che il 90% o più del mercato disposto a installare ed eseguire un'applicazione ASP.NET è anche in grado e disposto a utilizzare SQLExpress o SQL Server. Nella maggior parte dei casi risparmierai molto più tempo e denaro progettando per un solo server SQL di quanto non riuscirai mai a fare vendite aggiuntive dal supporto di più database.

2. Cerca di evitare di fare " tutto " configurabile tramite strumenti di amministrazione online. Ad esempio, sarai tentato di avere TUTTO il testo nell'applicazione configurabile dagli strumenti di amministrazione. È fantastico, ma è anche costoso. Lo sviluppo richiede più tempo, richiede di aumentare l'ambito della tua applicazione per includere un intero casino di strumenti di amministrazione che non avresti altrimenti necessario, e rende l'applicazione più complessa e difficile da usare per il 90% dei tuoi clienti a cui non importa il testo predefinito.

3. Valuta attentamente la localizzazione. Se non pensi di avere un grande mercato internazionale attenersi a una lingua. La localizzazione non è troppo difficile, ma complica un po 'ogni aspetto del tuo codice ... e questo si aggiunge molto a qualsiasi applicazione di qualsiasi dimensione. La mia regola empirica è indirizzare solo la lingua del mio mercato iniziale. Se l'app ha interesse in altri mercati, torno indietro e faccio la localizzazione nella versione 2.x dopo aver recuperato un po 'di denaro dalla versione 1.0 e ho dimostrato che l'applicazione ha un mercato praticabile in primo luogo. Ma se sai che sarai in più di una lingua o cultura, supporta la localizzazione fin dall'inizio.

4. Per la versione 1.0, non preoccuparti troppo dei moduli drop-in o delle API di servizio elaborate. Se hai già avuto molta esperienza in framework riutilizzabili, potresti avere questa roba nella versione 1.0, ma se non hai esperienza in questo tipo di architetture, perderai troppo tempo con queste funzionalità nella versione 1.xe tu probabilmente continuerà a sbagliare e dovrà comunque riprogettarlo nella versione 2.x.

5. Assicurati che l'applicazione abbia VERAMENTE un buon rapporto. Per il tipo di applicazione di cui stai parlando, questo è ciò che decide se l'applicazione ha anche un mercato. Hai bisogno di graziosi report non solo ordinabili / filtrabili sullo schermo, ma anche stampabili. Metti i tuoi soldi e il tuo tempo in questo fuori dal cancello.

Answer 2

La cosa più importante è progettarla in modo che sia completamente generica, cioè non ci sono informazioni specifiche per il cliente hard coded o embedded.

Tutto ciò che è specifico del client deve essere configurabile tramite metadati. Il modo in cui lo fai dipende completamente da te, ma i modi principali sono tramite XML, database o file delle proprietà.

Se lo si progetta in questo modo, potrebbe essere venduto a un numero qualsiasi di client che avranno ciascuno i propri file o dati di configurazione.

Answer 3

Abarax ha dato un'ottima risposta, sottolineo che dovresti prendere in considerazione la localizzazione, sia per le lingue parlate (inglese, francese, tedesco, ecc.) sia per la lingua dell'organizzazione, ad es. alcuni posti possono chiamarlo Timesheet, Docket o Ordine di lavoro, e ognuno gemerà e gemerà e gemerà se tutto non corrisponde a quello che hanno sempre chiamato qualcosa.

Answer 4

Se si utilizzano tecnologie open source, dedicare un po 'di tempo a conservare tutte le informazioni sulla licenza in un unico posto.