Organizzazione della soluzione / struttura del progetto e classi per l'applicazione Line of Business (LOB)

2

La domanda how-do-you-organiz-your-projects ha già qualche buona risposta. Mi piacerebbe avere una migliore comprensione di questa struttura suggerita :

MyApp.Core
MyApp.Model
MyApp.Presenter
MyApp.Persistence
MyApp.UI
MyApp.Validation
MyApp.Report
MyApp.Web

Supponendo che MyApp sia un client rich winforms per amministrare studenti, corsi, stanze e insegnanti

Diciamo che ho un controllo utente winforms per modificare le informazioni sul corso (nome del corso, chi lo insegna, in quale stanza e quali studenti si sono registrati per il corso). La classe sottostante riflette tutte le informazioni di cui ho bisogno per il controllo utente

public class CourseDetails{
    public int Id{ get; set;}
    public Course Course{ get; set;}
    public Teacher Teacher{get; set;}
    public Room Room{get; set;}
    public List<Student> StudentList{get; set;}
}

Dove metteresti questa lezione?

Metodi di MyApp.Model

Mi piacerebbe sapere quanto siano complesse o semplici le classi all'interno del namespace MyApp.Model shoud.

Il progetto MyApp.Model dovrebbe contenere solo classi molto semplici come

public class Course{
    public int CourseId{ get; set;}
    public string CourseName{ get; set;}
    public int CategoryId {get; private set;}

}
public class Teacher{
    public int TeacherId{ get; set;}
    public string TeacherName{ get; set;}
}

o dovrebbe MyApp.Model contenere anche

  • classi complesse come CourseDetails
  • metodi aggiuntivi per ogni classe come Save() o GetById() ?

Argomenti aggiuntivi

Dove (in quale progetto) dovrebbero essere implementate le interfacce e dove dovrebbe essere usata la base class.

Quando questo metodo aggiuntivo ( Save() , GetById() ) può essere ereditato da una classe base o essere contenuto nella classe che impone un'interfaccia che ha tutti i metodi per il salvataggio e la selezione.

public class CourseDetails: ModelBase{
    ...
}

public class ModelBase{
    public bool Save() {
        Console.WriteLine("do something clever to save each entity");
        return true;
    }
}

Ci scusiamo per non essere più chiari; Mi piacerebbe capire che tipo di cose (classi, interfacce, risorse, ecc.) Dovrebbero essere inserite in quale progetto e perché. Spero che tu abbia capito l'idea.

    
posta threeFourOneSixOneThree 18.07.2014 - 11:15
fonte

2 risposte

2

La struttura che stai delineando qui si chiama architettura a cipolla, conosciuta anche come porte e adattatori o architettura esagonale.

Il principio è che hai il nucleo dell'applicazione, e poi puoi mettere i livelli al di fuori di questo core, come un livello dell'interfaccia utente, un livello di persistenza, un livello di servizio e così via.

Definite le interfacce per la vostra applicazione nel vostro core e poi lasciate che i livelli esterni li implementino. In questo modo il tuo core rimane "puro" e se ad esempio vuoi cambiare il tuo meccanismo di persistenza da MySQL a MongoDB, si tratta di reimplementare l'interfaccia di persistenza definita nel core, in un altro modulo specifico per MongoDB.

Vedi: link e link

per una spiegazione più approfondita.

    
risposta data 17.08.2014 - 23:04
fonte
1

Dipende

Ovviamente la risposta dipende da diversi fattori:

  • tutti i file binari del progetto saranno condivisi tra le applicazioni?
  • tutti i file binari del progetto possono essere inseriti?
  • l'applicazione ha più livelli?

Se l'applicazione è autonoma, l'opzione migliore potrebbe essere quella di avere un singolo exe autosufficiente, in quanto fornisce un modello di implementazione estremamente semplice e semplice: xcopy. In questo caso, l'organizzazione dei file avviene tramite cartelle all'interno di un singolo progetto.

Questo suona in linea con la descrizione della tua applicazione, assumendo che la porzione web sia composta da codice client inteso per interfacciarsi con un archivio dati separato per i dati di amministrazione della classe.

In un'applicazione multilivello, potresti aver bisogno di 1 o più file binari per ogni livello e binari aggiuntivi per qualsiasi tipo condiviso su più livelli.

In generale, tuttavia, non dividerei progetti se non è necessario: YAGNI.

    
risposta data 18.07.2014 - 20:15
fonte

Leggi altre domande sui tag