architettura n-tier: posto migliore per conservare gli oggetti di business?

Question

dire che ho un architettura a 3 livelli (interfaccia utente, Business e dati). Di solito, creo un quarto progetto denominato "Modello" o "comune" per mantenere i miei oggetti di accesso ai dati e ciascuno degli altri progetti sarebbero quindi utilizzare questo progetto.

Ora sto lavorando su un progetto in cui alcuni dei miei oggetti di accesso ai dati hanno metodi come Salva () ecc che hanno bisogno di accedere al progetto di dati. Quindi, vorrei avere un riferimento circolare se ho cercato di utilizzare il progetto Modello / comune nel progetto di Data.

In questo scenario, dove è il posto migliore per tenere gli oggetti di accesso ai dati? Potrei tenerlo all'interno del progetto di dati in sé, ma poi il mio progetto UI, che ha bisogno di conoscere gli oggetti di accesso ai dati, avrei bisogno di accedere al livello dei dati, che non è buono.

Answer 1

Questo è quello che ho nel mio progetto.

1). Application.Infrastructure

• classi base per i businessobjects, busines oggetto di raccolta, classi di accesso ai dati e ai miei attributi personalizzati e programmi di utilità, come metodi di estensione, quadro di convalida generico. Questo determina l'organizzazione generale comportamento della mia applicazione .net finale.

2.) Application.DataModel

• Dataset tipizzato per il database.
• TableAdapters esteso per incorporare operazioni e gli altri caratteristiche di cui ho bisogno.

3). Application.DataAccess

• classi di accesso ai dati.
• luoghi stessi in cui le azioni di database vengono interrogati usando sottostante Dataset tipizzato.

4). Application.DomainObjects

• Gli oggetti business e collezioni di oggetti business.
• enumerazioni.

5.) Application.BusinessLayer

• Fornisce classi di gestione accessibili dal livello di presentazione.
• gestori HTTP.
• La mia classe di base pagina.
• Più le cose vanno qui ..

6). Application.WebClient o Application.WindowsClient

• Il mio livello di presentazione
• Prende riferimenti da Application.BusinessLayer e Application.BusinessObjects.

Application.BusinessObjects sono utilizzati in tutta l'applicazione e viaggiano attraverso tutti gli strati quando neeeded [salvo Application.DataModel e Application.Infrastructure]

Tutte le mie domande sono definiti solo Application.DataModel.

ritorna Application.DataAccess o prende gli oggetti di business come parte di qualsiasi operazione di accesso ai dati. Gli oggetti business sono creati con l'aiuto di attributi di riflessione. Ogni oggetto di business è contrassegnato da una mappatura degli attributi di indirizzare tabella nel database e proprietà entro l'oggetto di business sono contrassegnati con gli attributi mappatura di indirizzare coloumn nella rispettiva tabella del database.

Il mio quadro di convalida mi permette di convalidare ogni campo con l'aiuto di designato ValidationAttribute.

Il mio framrwork utilizza pesantemente attributi per automatizzare la maggior parte dei compiti noiosi come la mappatura e validazione. Posso anche novità come nuovo aspetto nel quadro.

Un oggetto di business campione sarebbe simile a questa nella mia applicazione.

User.cs

[TableMapping("Users")]
public class User : EntityBase
{
    #region Constructor(s)
    public AppUser()
    {
        BookCollection = new BookCollection();
    }
    #endregion

    #region Properties

    #region Default Properties - Direct Field Mapping using DataFieldMappingAttribute

    private System.Int32 _UserId;

    private System.String _FirstName;
    private System.String _LastName;
    private System.String _UserName;
    private System.Boolean _IsActive;

    [DataFieldMapping("UserID")]
    [DataObjectFieldAttribute(true, true, false)]
    [NotNullOrEmpty(Message = "UserID From Users Table Is Required.")]
    public override int Id
    {
        get
        {
            return _UserId;
        }
        set
        {
            _UserId = value;
        }
    }

    [DataFieldMapping("UserName")]
    [Searchable]
    [NotNullOrEmpty(Message = "Username Is Required.")]
    public string UserName
    {
        get
        {
            return _UserName;
        }
        set
        {
            _UserName = value;
        }
    }

    [DataFieldMapping("FirstName")]
    [Searchable]
    public string FirstName
    {
        get
        {
            return _FirstName;
        }
        set
        {
            _FirstName = value;
        }
    }

    [DataFieldMapping("LastName")]
    [Searchable]
    public string LastName
    {
        get
        {
            return _LastName;
        }
        set
        {
            _LastName = value;
        }
    }

    [DataFieldMapping("IsActive")]
    public bool IsActive
    {
        get
        {
            return _IsActive;
        }
        set
        {
            _IsActive = value;
        }
    }

    #region One-To-Many Mappings
    public BookCollection Books { get; set; }

    #endregion

    #region Derived Properties
    public string FullName { get { return this.FirstName + " " + this.LastName; } }

    #endregion

    #endregion

    public override bool Validate()
    {
        bool baseValid = base.Validate();
        bool localValid = Books.Validate();
        return baseValid && localValid;
    }
}

BookCollection.cs

/// <summary>
/// The BookCollection class is designed to work with lists of instances of Book.
/// </summary>
public class BookCollection : EntityCollectionBase<Book>
{
    /// <summary>
    /// Initializes a new instance of the BookCollection class.
    /// </summary>
    public BookCollection()
    {
    }

    /// <summary>
    /// Initializes a new instance of the BookCollection class.
    /// </summary>
    public BookCollection (IList<Book> initialList)
        : base(initialList)
    {
    }
}

Answer 2

Non credo che avete il vostro n-tier perfettamente ragione. Sembra che si sta costruendo più sistemi 2-tier.

In un progetto reale 3-tier, solo il vostro livello di dati è consentito di parlare con il database. Bisogna che con il vostro "modello" o "progetti comuni". Questi progetti sono il tuo livello di dati. Ma dove si vira fuori è che solo livello aziendale dovrebbe essere consentito di parlare con loro. Il codice di presentazione non dovrebbe essere consentito di parlare con i progetti di data tier a tutti.

n-Tier arriva quando si dispone di più di 3 "livelli", ma lo stesso principio applicatori: ogni livello solo sa come usare (e ha solo bisogno di un riferimento a) quello sottostante, e quindi fornisce un'API per il livello sopra di esso. Nei miei progetti, prendo la presentazione tipica, affari, e livelli di dati e fornire un livello 4 ° "traduzione" tra le imprese e dati. In questo modo il livello dati può tornare tipi generici come set di dati, DataTable e DataRow, e il livello di business solo deve lavorare in termini di oggetti di business fortemente tipizzato. Il livello di traduzione solo converte tra gli oggetti dati generici e oggetti fortemente tipizzato. In questo modo una modifica a uno dei livelli tradizionali è meno probabile che richiedono un cambiamento in un altro.

Answer 3

Lo strato di dati deve memorizzare le informazioni in termini di righe e colonne (forse utilizzando DataSet tipizzati, se vi piace), se si utilizza un backend relazionale. Non ci sono "oggetti di business".

Il livello di commercio dovrebbero usare i tuoi "oggetti di business". Può avere un riferimento al progetto di BusinessObjects.

In sintesi:

• UI ha riferimenti al business e BusinessObjects
• Business ha riferimenti a BusinessObjects e dati

Spero che questo aiuti.

Answer 4

Ho un progetto di BusinessObjects, lato server memorizzare le mappature (ORM) e un servizio corrispondente DataAccess esponendo le operazioni CRUD su di loro (e anche gli altri come GetAll), ecc.

Answer 5

Vorrei suggerire la creazione e l'interfaccia di ciò che si vuole nel progetto del modello, e l'attuazione di tale definizione nel livello dati. In questo modo tutti e tre (quattro?) I progetti possono utilizzare tale definizione, senza sapere come è implementato.

Answer 6

A mio parere, solo lo strato di business deve essere a conoscenza degli oggetti di accesso ai dati. Dovrebbe usarli per operazioni di dati applicando le proprie regole di business e la logica, poi restituire oggetti muti (ad esempio oggetti di trasferimento dati) allo strato di interfaccia sopra.

Si potrebbe usare qualche cosa come automapper per mappare automaticamente tra i propri dati e oggetti di business.

Answer 7

E 'davvero dipende dal modello, se si utilizza MVC (anteriore del modello Controller), il modello è la rappresentazione specifica del dominio dei dati su cui opera l'applicazione (in genere un aiuto ORM con questo) si usa un progetto di Data per questo le classi.

I modelli non sono oggetti di accesso ai dati, quindi l'accesso dei dati diventa in forma di depositi in un progetto diverso. Servizi per Business Rules e, infine, il progetto Web. In questo approccio l'Data.dll viene fatto riferimento in tutti i progetti. Il modello è come onnipresente.

DATA(Domain Model) -> REPOSITORY(Data Access) -> SERVICE(Business Rules) -> WEB