Carpool architettura logica

6

Sto progettando un sistema di car pooling (i conducenti possono pubblicare i loro percorsi e i passeggeri possono iscriversi a loro) con WebServices (axis2) e client Android (ksoap2).

Ho avuto problemi con l'architettura logica del sistema e mi sono chiesto se questa architettura è a posto.

E un'altra domanda: per quell'architettura (se è ok), come sarebbe la struttura dei pacchetti?

Suppongo che qualcosa del genere:

(in Android)
package org.carpool.presentation
* Tutte le attività qui (e forse il pattern mvc)

(Nel server)
package org.carpool.services
* Interfacce pubbliche (ad esempio: registro (utente utente), publishRoute (percorso percorso))

package org.carpool.domain
* Pojos (ad esempio: User.java, Route.java, ecc.)

package org.carpool.persistence
* Interfaccia e implementazione Dao (jdbc o hibernate)

    
posta Enrique Marcos 25.11.2011 - 00:10
fonte

3 risposte

1

Sì, IMO che l'architettura è fantastica, e lo consiglierei (non che questo significhi molto, lol). Ha funzionato per me nel passato e nel presente ... Sebbene la mia esperienza fosse sul lato .net delle cose (MVC / WCF / POCO / ENTITY | MSSQL) .. ma forma un livello di architettura, la stratificazione è quasi identica.

ottima idea .. buona fortuna

    
risposta data 30.01.2012 - 20:18
fonte
1

Nel complesso, sembra buono. Ma vorrei riflettere su come scalare questo se sarà un sistema pubblico. Se si prevedono modifiche minime ad alcuni dati (informazioni di percorso) ma si aspetta che venga letto molto, è necessario un tipo di soluzione di memorizzazione nella cache sul back-end. Dovresti anche pensare al ridimensionamento della scrittura, se ti aspetti un sacco di input.

Infine, dovresti catturare i tuoi pensieri attorno alle tue dipendenze esterne per questo (google maps? Facebook?). A questo livello, queste ipotesi giocheranno un ruolo importante nella comprensione del posizionamento del prodotto.

    
risposta data 17.03.2012 - 03:28
fonte
1

Un business carpool si basa su una buona storia di back-end. Alcune sfide che possono emergere sono

  1. Un sistema di back-end per car pooling è l'efficienza della ricerca. Se la ricerca è rapida ed efficiente, l'intero sistema si rivela utile. Man mano che il database cresce, la ricerca può solo peggiorare. La domanda è: come mantenere efficiente la ricerca man mano che il database cresce.
  2. Quale modello aziendale segui, è la chiave. Se state seguendo un sistema di taxi, e non un sistema di carpool, quale sarà l'impatto di questo cambiamento sul vostro progetto? Dovrai cambiare anche l'intero back-end? Affare molto costoso.
  3. Concorrenza, c'è così tanto là fuori, ma francamente non abbastanza :). i siti web carpool là fuori sono lasciati crescere sotto "la grazia di Dio". I proprietari dei siti web sviluppano il sito web come un blog e "sperano" che le persone possano semplicemente entrare.
  4. Ogni sito web offre una soluzione diversa, ma non è in grado di incontrarsi a causa delle sfide sopra descritte. Detto questo, c'è un valore in questo business dal momento che ci sono così tante opportunità.

Abbiamo pensato a questo qualche anno fa e abbiamo sviluppato un motore di base che consentirà alle aziende di utilizzare il nostro framework e creare il proprio sito web di car pooling, app per dispositivi mobili. Devi solo preoccuparti dei tuoi livelli aziendali superiori. Pensaci, invece di iniziare a zero, integra il nostro framework e usa le chiamate api come AddUser, AddVehicle, AddCarProvider, SearchCarProvider.

    
risposta data 25.08.2012 - 06:50
fonte

Leggi altre domande sui tag