Riutilizzare la logica aziendale tra Web e API

4

Abbiamo un sito Web e due app mobili che si connettono tramite un'API. Tutte le piattaforme fanno esattamente le stesse cose. In questo momento la struttura è la seguente:

  • sito web. Gestisce modelli, controllori, viste per il sito web. Esegue anche tutte le attività in background. Quindi se un utente crea un luogo, tutto viene eseguito in questo codice.
  • API. Gestisce modelli, controllori e restituisce un JSON. Se un utente crea una posizione nell'app mobile, il luogo viene creato qui. Dopo, aggiungiamo un'attività in background per aggiornare altri campi. Questa attività in background viene eseguita dal sito Web.

Stiamo rifacendo tutto, quindi è il momento di migliorare l'approccio. Qual è il modo migliore per riutilizzare la logica aziendale, quindi ho solo bisogno di codificare l'inserimento / modifica / eliminazione del luogo & altre azioni correlate in un solo posto?

Un approccio orientato ai servizi è una buona idea? Ad esempio:

  • Servizio. Ha i modelli e ottiene, aggiunge, aggiorna ed elimina informazioni dal DB.
  • sito web. Invia le informazioni al servizio e rende HTML.
  • API. Invia informazioni al servizio e restituisce JSON.

Alcuni problemi che ho trovato:

  • Più lavoro iniziale? Non sono sicuro ..
  • Può funzionare più lentamente. Qualche esperienza?

I vantaggi:

  • Abbiamo solo la logica di business in un unico posto, sia per web che api.
  • È più semplice da ridimensionare. Possiamo mettere ogni pezzo su server diversi.

Altre soluzioni

  • Duplica il codice e fai attenzione a non dimenticare nulla (fai test!)
  • DUplicate del codice ma eseguite attività in background che aggiornano i campi correlati ed eseguono altre cose (e-mail, indicizzazione ...)

Un "piccolo" dettaglio è che siamo 1,3 persone nel back-end, per ora;)

    
posta fesja 13.12.2012 - 01:48
fonte

2 risposte

11

L'ho incontrato prima (molte volte) e quello che ho finito per fare è preferibile:

Porta la BL fuori dal sito web. Rendi il sito Web un consumatore dell'API. Tratta il sito come solo un altro client della tua API. La tua API IS il servizio.

Se pensi di aver bisogno di metodi API speciali solo per il sito web, ripensaci! Se è buono per l'oca, è buono per il papero. Se davvero hai davvero bisogno di funzionalità speciali per il sito web, ti suggerirei che ciò che hai veramente trovato è una differenza nel "profilo utente" e quindi questa è una situazione in cui l'API dovrebbe ancora supportare le funzioni "speciali", ma poi tu controllarli tramite autorizzazione.

Non sei convinto?

Porta il paradigma un ulteriore passo avanti ...

L'app del telefono è in esecuzione su una piattaforma in cui viene eseguito bytecode, l'app risiede nel telefono e utilizza i servizi API tramite HTTP / JSON

Il sito Web è un'app in esecuzione su una piattaforma in cui è eseguito HTML + Javascript, l'app risiede in un browser e utilizza i servizi API tramite HTTP / JSON

Stessa cosa!

Estendilo a tablet, TV, altre piattaforme telefoniche, plug-in, app di terze parti, mashup, ...

Un sacco di diverse esperienze utente tutte collegate a un'API comune.

La tua app è l'API. Il sito web è solo un client (di molti)

    
risposta data 13.12.2012 - 04:36
fonte
1

Appena una domanda qui ma alcuni pensieri:

Chiedi: "Altri lavori iniziali?" rispetto a cosa? Questo materiale delle attività in background suona più problemi per l'installazione.

La soluzione di attività in background sta arrivando alla stessa cosa, invoca codice comune / condiviso. Solo tu lo fai indirettamente. Come si può essere una soluzione migliore o più gestibile?

Lavorare principalmente con attività in background complica anche gli scenari in cui è necessario conoscere il risultato di un'attività. L'attesa e il marshalling dei valori di ritorno sarà un peso e aggiungerà complessità.

Quindi chiedi: "Può funzionare più lentamente. Qualche esperienza?" l'impostazione di attività in background da gestire con un altro processo non sarà mai più veloce, quindi richiamerà l'attività direttamente e immediatamente (preferibilmente nello stesso processo).

Il vantaggio di ridimensionamento che proponi introduce il dover attraversare costantemente i confini del processo o, peggio, i confini della rete. Preferirei creare un livello di servizio in corso, se possibile. E crea un livello intermedio se davvero necessario.

La duplicazione del codice non è mai una soluzione per quanto mi riguarda, sta richiedendo un disastro di manutenzione.

    
risposta data 13.12.2012 - 02:14
fonte

Leggi altre domande sui tag