conception n-tier - meilleur moyen de transmettre des données objet récupération

voix
1

J'utilise une conception 3 niveaux de base. Pour des raisons de flexibilité (et d'essai), je voulais que la couche de données pour être abstraite et préciser la classe concrète dans mon code. Mais, comment dois-je passer ce long à mes objets métier. Voici un exemple (code pseudo):

abstract class IDataLayer
{
    PersonData GetPerson(int); //PersonData would be a row of data from a table for example
    JobData[] GetJobs(int);
    void UpdatePerson(PersonData);
}

class ConcreteDataLayerSQL : IDataLayer
{
...
}
class ConcreteDataLayerXML : IDataLayer
{
...
}

class PersonBAL
{
    void PersonBAL(personId)
    {
        //What goes here?
    }

    JobBAL[] GetJobs()
    {
       //What goes here?
    }
}
class Program
{
    static void Main()
    {
        person = new PersonBAL(1);
    }
}

Le problème est, comment PersonBAL savoir quels ConcreteDataLayer à utiliser? Je pense entre quelques options:

1: transmettre la couche de données en béton à l'autre. Cela devient une douleur lorsque vous commencez à ajouter de nouvelles classes qui ont besoin d'interagir avec la couche de données (quelque chose comme nouveau PersonBAL (IDataLayer, int), puis nouvelle JobBAL (IDataLayer, int), etc etc)

2: Création d'un objet statique qui contient des données qui couche à utiliser (lire: variable globale)

D'autres idées?

Créé 27/08/2009 à 01:47
source utilisateur
Dans d'autres langues...                            


3 réponses

voix
1

Le problème que vous essayez de résoudre est « l'injection de dépendance ».

Si l'on suppose que ce code .NET (langue psuedo code ressemble beaucoup à C #), vous voudrez peut-être regarder dans un cadre comme Spring.NET qui est conçu pour ce genre de chose.

Créé 27/08/2009 à 02:02
source utilisateur

voix
0

vous pouvez mettre une couche d'indirection dans votre code afin que vous jamais directement construit un PersonBALlieu que vous avez PersonBALFactoryque vous utilisez pour construire vos PersonBALinstances. L'usine a la dépendance à l'égard IDataLayer qui est passé à travers le constructeur (et qui est branché à votre démarrage de l' application du temps) et vous dire l'usine pour créer personne utilisant un personID et la crée une nouvelle PersonBAL passer l'ID et le IDataLayer. De cette façon , l'utilisateur n'a pas besoin d'être concerné par ce qui IDataLayer que vous utilisez, il est mis en place dans la configuration des applications au démarrage, l'utilisateur demande tout nouveau PersonBAL en utilisant les informations qu'ils savent.

cadres DI vous aider à configurer tous l'injection de dépendance afin que les types corrects sont passés dans les constructeurs et fera la configuration des usines (et des choses qui ont une dépendance à l'égard des usines) automatiques et plus simples une fois que vous avez beaucoup d'usines ou des graphiques de grande dépendance.

Créé 25/11/2010 à 12:24
source utilisateur

voix
0

Je pense que le passage de la classe dans chaque constructeur serait difficile pour la raison que vous avez énumérés et parce que la modification du code à utiliser une autre classe serait une corvée sujette à erreur.

L'injection de dépendance est au cœur du cadre de printemps. Spring utilise des fichiers de configuration XML pour décrire les relations entre les classes. Pour votre cas d'utilisation, vous pouvez spécifier le type spécifique que vous souhaitez instancier dans la configuration, donc il vous suffit de faire un changement pour changer les implémentations.

Le printemps est un cadre bien connu et testé, mais bien sûr vous n'avez pas besoin pour résoudre le problème. Vous pouvez très bien vous écrire propre code pour les fichiers de configuration. De toute façon, cela est essentiellement une variante de la deuxième option que vous avez mentionné.

Créé 27/08/2009 à 17:23
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more