applicazione web multi-client, dovrei usare controlli utente personalizzati o un controllo utente comune

Question

applicazione web multi-client, dovrei usare controlli utente personalizzati o un controllo utente comune

#1 da (1 voti)

1

Supponiamo che la mia azienda costruisca un complicato sistema di formazione di moduli web asp.net. Uno dei moduli è la registrazione basata sul web. Per renderlo flessibile, decidiamo di usare il controllo utente (ascx) con il motore delle regole (flusso di lavoro) che regola tutta la logica aziendale. Pertanto, in futuro, per diversi client, possiamo semplicemente configurare le regole esistenti di base o aggiungere nuove regole. (Regole memorizzate in db o XML per client).

Ora la domanda è come gestire i controlli utente (ascx)? La mia opinione è che diversi client costruiscono il controllo degli utenti da zero. l'altra voce è come riutilizzare i controlli utente esistenti.

architecture webforms asp.net

posta ValidfroM 15.11.2012 - 22:42

fonte

1 risposta

Leggi altre domande sui tag architecture webforms asp.net

I servizi aziendali devono intersecare i contesti? Strategia per il controllo delle versioni su un repo pubblico

score 1 · Accepted Answer

Dipende bene, se ogni cliente ha le proprie funzioni che sono uniche nel modo in cui usano l'applicazione, allora, costruisci i controlli utente da zero.

Se non lo fanno, in pratica fanno tutti la stessa cosa, ne hanno solo bisogno di essere marchiati o di qualsiasi altra cosa per la loro società, quindi è inutile reinventare la ruota.

La mia azienda lo gestisce in questo modo: abbiamo una piattaforma centrale su cui tutti i nostri siti web sono basati. Se un sito Web e un'applicazione di un particolare modulo non sono così diversi dal nostro database generico di base, vengono creati su quella piattaforma centrale.

Se il modulo di domanda è significativamente diverso, dirammo la nostra piattaforma principale e creiamo un nuovo progetto per quel singolo programma. In modo che non ci ritroviamo con un sacco di codice specifico per i nostri spaghetti nei nostri modelli / controller.

TLDC : non decidere ora, sii flessibile, in definitiva dovrebbe essere determinato dal cliente; quale creerà la minor quantità di lavoro, e la piattaforma più gestibile.