Architecture à 3 niveaux - Besoin d'un exemple

C'est ce que j'ai dans mon projet. Plus qu'un traditionnel de l'architecture 3 tiers.

1.) Application.L'Infrastructure

• Classes de Base pour tous businessobjects, les milieux d'affaires de l'objet de la collecte, les données d'accès classes et mes attributs personnalisés et des services, les méthodes d'extension, Générique framework de validation. Ce qui détermine le comportement général de l'organisation de mon dernier .net application.

2.) Application.DataModel

• Dataset typé pour la Base de données.
• TableAdapters étendu de manière à inclure les Transactions et les autres fonctionnalités dont j'ai besoin.

3.) Application.DataAccess

• Classes d'accès aux données.
• Réelle de l'endroit où les actions de Base de données sont interrogés à l'aide de sous-jacents Dataset Typé.

4.) Application.DomainObjects

• Les objets d'entreprise et d'Affaires à des collections d'objets.
• Enums.

5.) Application.BusinessLayer

• Fournit les classes manager accessible à partir de la couche de Présentation.
• HttpHandlers.
• Ma propre Page de la classe de base.
• Plus les choses vont ici..

6.) Application.WebClient ou Application.WindowsClient

• Ma couche de présentation
• Prend références de l'Application.BusinessLayer et de l'Application.BusinessObjects.

Application.BusinessObjects sont utilisés dans l'application et qu'ils voyagent à travers toutes les couches à chaque fois que neeeded [à l'exception de l'Application.Modèle de données et l'Application.Infrastructure]

Toutes mes requêtes sont uniquement déterminés par la Demande.DataModel.

Application.DataAccess retourne ou prend Business objects dans le cadre de tout accès aux données de fonctionnement. Entreprise les objets sont créés avec l'aide de la réflexion attributs. Chaque objet métier est marqué avec un attribut de la cartographie à la table cible dans la base de données et les propriétés à l'intérieur de l'objet de l'entreprise sont marquées avec des attributs de la cartographie pour cible coloumn dans la base de données de la table.

Mon framework de validation me permet de valider chaque champ avec l'aide de désigné ValidationAttribute.

Mon framrwork lourdement utilise des Attributs pour automatiser la plupart des tâches fastidieuses telles que la cartographie et de la validation. Je peux aussi nouvelle fonctionnalité nouvel aspect dans le cadre.

Un exemple de business object serait ressembler à ceci dans mon application.

De l'utilisateur.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)
{
}
}

Par "niveau" voulez-vous dire par "couche" dans votre logiciel de pile? Le mot "niveau" est mieux utilisé pour décrire la physique des composants de votre système. Si vous utilisez ASP.NET, vous avez probablement déjà un "3 niveaux" système -

1. Navigateur l'affichage des pages web
2. IIS, le Serveur d'hébergement de votre application
3. Serveur de base de données avec votre base de données

Mais vous êtes peut-être mettre votre code dans un seul logiciel "couche" - plus précisément, le fichier code-behind de vos pages aspx. Vous souhaitez vous déplacer à partir d'une seule couche d'une couche de 3 approche. Le classique "3 couches" de l'architecture logicielle se compose des éléments suivants -

1. Couche De Présentation

2. De la Couche Logique métier (BLL)

3. Couche d'Accès aux données (DAL)

le texte d'alt http://weblogs.asp.net/blogs/fredriknormen/WindowsLiveWriter/UsingWebServicesina3tierarchitecture_134F6/3tier_2.jpg

Pour un type ASP.NET app, vous pouvez appliquer ce qui suit. Tout d'abord, vous créez un LINQ2SQL fichier (.dbml) contenant les objets de votre base de données access. C'est votre Couche d'Accès aux Données (DAL).

Ensuite, vous pouvez créer une DLL pour contenir votre de la Couche Logique Métier (BLL). Cette couche permettra d'accéder à la base de données via le DAL, la manipuler comme requis, puis l'exposer via une interface simple. Par exemple, si votre application affiche une liste de clients, de votre BLL pourrait avoir une fonction publique appelée GetClientList() qui retourne une liste de clients.

Enfin, vous définissez votre code derrière fichiers pour instancier la BLL et le fil jusqu'à l'composants de l'interface. C'est votre Couche de Présentation. Par exemple, il peut prendre les données renvoyées par votre GetClientList() de la fonction et de la lier à une grille de données sur le formulaire web. L'idée est d'avoir la présentation de la couche aussi mince que possible.

Cela semble un peu longues à décrire, mais c'est assez simple une fois que vous avez fait une couple de fois. Vous trouverez que la séparation de votre application comme cela sera beaucoup plus facile à maintenir, comme le la séparation des préoccupations conduit à plus propre code. Vous trouverez également beaucoup plus facile de mettre à niveau ou remplacer la couche de présentation, car il contient très peu d'astuce. Enfin, vous arriverez à un point où vous avez un certain nombre de très utile BLL bibliothèques que vous pouvez facilement consommer dans de nouvelles applications, qui améliore considérablement la productivité.

Architecture de niveau 3 peut avoir différentes significations selon le contexte. Généralement, cela signifie que les responsabilités dans l'application sont réparties entre les différents niveaux. Généralement, niveau 3 se réfère à :

• couche de présentation" (véritable interface utilisateur)
• logique de niveau (application/logique métier)
• couche de données (base de données, stockage de données)

Les détails varient en fonction de l'application.

Wikipédia, comme d'habitude, a une belle vue d'ensemble: http://en.wikipedia.org/wiki/Multitier_architecture

Un exemple simple serait une entreprise typique d'application:

• présentation: navigateur, ou de la graisse client
• niveau logique: la logique d'entreprise, généralement dans un serveur d'application (basé sur J2EE, ASP.NET ou quoi que ce soit)
• couche de données: une base de données, généralement un SGBDR comme MySQL ou Oracle

Un bon tutoriel, complet, contrôle de la source de téléchargement d'un bien écrite niveaux d'application serait ici:

http://nerddinnerbook.s3.amazonaws.com/Intro.htm

Ce n'est pas un tutoriel sur l'architecture à plusieurs niveaux, mais c'est bien écrit, d'application et donne un aperçu des raisons pour lesquelles vous pourriez envisager de cette architecture.

En outre, comme cela a été brièvement évoquée ci-dessus, c'est sur la tenue de votre logique/stockage/code de présentation séparé, donc si vous devez modifier un (e.g changer de asp.net frontale pour une application de bureau), il n'est pas si difficile à faire.