MVC: il modello "Utente" diventa grande e affollato. I metodi che eseguono operazioni CRUD su dati di relazione uno-a-molti possono essere in modelli diversi?

Question

MVC: il modello "Utente" diventa grande e affollato. I metodi che eseguono operazioni CRUD su dati di relazione uno-a-molti possono essere in modelli diversi?

#1 da (1 voti)
#2 da (1 voti)

3

Nella maggior parte dei progetti web MVC esiste una classe utente. Molte volte un utente ha qualcos'altro in una relazione uno-a-molti, cioè ordini.

Se disponiamo di una classe utente con molti ordini, i metodi che aggiungono, modificano o eliminano gli ordini per un utente devono essere inseriti nella classe utente o in una classe Order separata?

cioè.

1.

user.add_order(order_name)   //Instance method

vs

2.

Order.add_order_for_user(user_id, order_name)   //Static method

o in alternativa,

3.

order = new Order(user_id,order_name)
order.save()

(Inoltre, nel caso dell'opzione 3, dovrebbe essere combinato con l'opzione 1 e inserire quel metodo)?

Il mio problema principale con l'opzione 1 è che il modello dell'utente tende a diventare enorme in termini di dimensioni. Questo viola l'SRP? Ad esempio, in uno dei miei progetti un utente ha molte "cose" come utenti amici, feed, file caricati, avvisi, punizioni e la lista continua. Fondamentalmente sto aggiungendo i metodi CRUD per tutte quelle "cose" che un particolare utente ne ha molte, nella classe User stessa. È una cosa brutta e dovrei diffondere i metodi CRUD in diverse classi?

Tuttavia, uno dei vantaggi dell'opzione 1 è che posso controllare la logica in quei metodi CRUD utilizzando gli attributi dell'oggetto utente corrente, senza dover interrogare l'utente. Ad esempio, se ho un metodo "add_file" posso verificare se lo spazio file totale dell'utente utilizzato (un attributo dell'utente) è inferiore a un massimo senza aver fatto un'altra query.

design class mvc relationships model

posta user2225945 18.04.2014 - 04:25

fonte

2 risposte

Leggi altre domande sui tag design class mvc relationships model

Architettura N-Layer Che cos'è un ambiente di database?

score 1 · Answer 1

Generalmente tutti i nomi dovrebbero avere una propria classe, un modello nel caso di usare il modello mvc. Utente e ordine sono due cose separate, quindi dovresti avere due modelli. Tuttavia, sono correlati in modo che il modello di dati debba avere una chiave o una tabella bridge per mettere in relazione gli utenti con gli ordini. Un utente ha ordini ma un utente non viene aggiornato da un ordine, ma più precisamente un record di ordine viene aggiornato, quindi vorresti usare il modello di ordine per le tue operazioni di crudismo.

Il problema con lo scenario 1 è che il tuo codice sarà strettamente associato a un utente.

Inoltre, sembra che dovresti passare l'ID ordine e l'ID utente, non il nome dell'ordine per mantenere le buone pratiche usando i vincoli appropriati.

score 1 · Answer 2

Se il tuo caso è l'elaborazione degli ordini che si concentra sugli ordini, credo che Order sia l'entità di aggregazione radice che ha un riferimento all'entità User , ad esempio:

class Order {

   User user   

   Payment payment

   Delivery delivery

   ...
}

Se vuoi selezionare Order basato su User , puoi creare nuovi metodi nel tuo repository come:

interface OrderRepository {

   public List<Order> findOrderByUser(User user); 

   public List<Order> findOrderByUserAndStatus(User user, OrderStatus status);

}

Se la logica aziendale richiede alcuni calcoli in User in base a Order , è possibile aggiungere Order richiesto a User . Di solito non è tutto Order che è stato creato da quell'utente (la tua preoccupazione è che siano troppi per essere salvati in User , giusto?). Ad esempio, può essere pendingOrder :

class User {

    List<PendingOrder> pendingOrders = []

    BigDecimal creditLimit

    boolean allowNewOrder() {
       ...  // check if sum of pendingOrders is not more than allowed limit
    }
}

Credo che questo renderà le tue classi di dominio più ricche.