Vuoi qualche input di architettura per aiutarti con i requisiti attuali e i requisiti futuri (sconosciuti) :-)

2

BACKGROUND: sto iniziando a progettare un progetto web usando asp.net mvc.

Userò un'architettura molto comune in cui ho i seguenti livelli:

  1. Servizio
  2. Biz
  3. Dati
  4. Dominio

Il livello di servizio interagisce con i livelli di Biz, Dati e Dominio. I controller mvc avranno il livello di servizio iniettato in essi utilizzando un framework DI. I controller dovranno essere a conoscenza delle interfacce del livello di servizio e faranno riferimento agli oggetti Dominio (POCO).

Il front-end sarà HTML5 + Javascript.

Mi è stato detto di tenere presente che è necessario esporre porzioni di questo sito Web ai dispositivi mobili. Le porzioni da esporre tramite dispositivi mobili devono essere definite :-).

Durante il rendering del sito posso semplicemente avere un layout mobile che esegue il rendering su un dispositivo mobile. Ma una cosa mi ha detto che gli utenti di dispositivi mobili potrebbero volere funzionalità aggiuntive che il sito Web non espone.

Forse vogliono accedere a una funzionalità che può essere fornita solo da un'applicazione mobile nativa. Ehi, io non compongo questi requisiti, questo è quello che mi è stato detto: -).

PENSIERI: il mio livello di servizio è il gateway per l'archiviazione di oggetti nel mio database.

Per qualsiasi potenziale dispositivo mobile nativo pensavo di utilizzare l'API Web per avvolgere il mio livello di servizio.

Quello che voglio fare ORA è focalizzarmi sulla mia applicazione asp.net mvc e preoccuparmi solo delle app native per dispositivi mobili quando tali requisiti diventano più definiti.

DOMANDA: fornirebbe eventuali vantaggi per codificare il livello API Web ora e i miei controller mvc lo utilizzano?

Professionisti per la creazione dell'API Web ora

  1. Sarà codificato e pronto se / quando un'app mobile nativa sarà online.

Contro per la creazione dell'API Web ora

  1. È un sovraccarico che non è necessario, specialmente se ospito WebAPI in un processo separato o in un altro sito oltre al mio sito originale mv.net asp.net.
  2. La tecnologia è abbastanza nuova e saranno in arrivo i potenziamenti. Se aspetto fino a tardi alcuni problemi verranno risolti.
  3. Chi lo sa, i miei utenti potrebbero non volere mai un dispositivo mobile nativo e la funzione non viene mai utilizzata.
  4. Il codice diventa più complesso a causa del fatto di dover mantenere il livello API web ora.

    Sto guardando non preoccuparsi del livello API Web per ora e semplicemente codificandolo quando necessario.

    In genere non mi preoccupo di scrivere per funzionalità che devono ancora essere definite. Ma ho pensato che non sarebbe stato male chiedere, non sai mai cosa sta facendo un brillante programmatore anticonformista allo stato brado: -).

posta RDotLee 08.01.2013 - 23:45
fonte

2 risposte

3

Considererei il tuo livello WebAPI come un livello di interfaccia utente (non grafico), uguale al livello MVC.

Inserisci il maggior numero possibile di codice non UI nel livello Service (o inferiore) e scrivi il livello MVC per accedervi, mantenendo i controller MVC il più sottili possibile.

Successivamente, quando si desidera fornire l'accesso ai client mobili (o altri), scrivere il livello WebAPI per accedere allo stesso livello di servizio, mantenendo i controller WebAPI il più sottili possibile, esponendo solo le funzionalità che si desidera esporre attraverso l'API.

Non mi preoccuperei di scrivere il tuo livello MVC per accedere al livello di servizio tramite WebAPI. Non vedo il punto, purché tutta la logica aziendale comune sia nel livello Servizio; In realtà non guadagni nulla (eccetto un altro strato di riferimento indiretto).

Il pezzo WebAPI sarà relativamente veloce da scrivere, assumendo che tu abbia scritto bene il tuo livello di servizio durante la fase di costruzione di MVC.

    
risposta data 09.01.2013 - 00:07
fonte
1

Sono totalmente d'accordo con l'approccio YAGNI, tuttavia, vedo il principio "YWBFI o trarrai vantaggio da esso" (lo hai appena inventato)? entrare di nascosto. L'accesso a dati / oggetti da un livello di servizio attraverso uno "schema" di URL ti darà una grande flessibilità e l'API Web è letteralmente solo alcuni attributi che inserisci nelle tue classi esistenti / altamente utilizzabili e ottieni un ottimo routing RESTful, che di nuovo offre una grande flessibilità.

Vorrei creare tanto in un livello di accesso di tipo API, quindi ogni cliente può decidere autonomamente come implementare l'API, incluse le tue app.

Poiché l'utilizzo della funzionalità dell'API WEB è così semplice, non vedo quanto sovraccarico possa realmente aggiungere rispetto ai benefici che riceverete sia a breve che a lungo termine.

    
risposta data 08.01.2013 - 23:58
fonte

Leggi altre domande sui tag