6
votes

Couche d'accès aux données et objets d'entreprise

Je ne sais pas si j'ai la terminologie correcte, mais je suis un peu confus sur la manière de configurer mon système à 3 niveaux.

permet de dire que j'ai une table d'utilisateurs dans ma DB.

Dans mon DAL, j'ai une classe UserDB qui appelle les PROC stockés dans He DB pour insérer, mettre à jour, supprimer. J'ai également une classe UserDétails utilisée dans UserDB pour revenir et transmettre des objets.

Alors maintenant, je ne sais pas comment utiliser cela dans ma couche logique d'entreprise. Ai-je besoin d'une autre classe d'objet BLL pour les utilisateurs? Si oui, cela ne serait-il pas redondant? Ou est-ce que je viens d'utiliser la classe UserDétails tout au long de mon BLL?

data-access-layer

0 commentaires

3 Réponses :

4
votes

Recherchez un concept appelé «conception pilotée sur le domaine» - la plus grande chose que vous utilisez ce qu'on appelle un motif de référentiel (tel que votre classe UserDB) en tant qu'adaptateur de la base de données, ainsi que d'une usine. Vos objets métier, ou objets de domaine, intégrent ensuite la logique commerciale en elles-mêmes et peuvent gérer des interactions avec d'autres objets métier.

Quelle technologie utilisez-vous? Quelque chose comme Aciverecord peut probablement vous aider beaucoup.

0 commentaires

2
votes

Vous appliqueriez généralement des règles commerciales dans votre BLL. Par exemple, vous pourriez autoriser les employés réguliers du centre d'appels à offrir une réduction de 10% sur le nouveau service, mais permettent à un responsable d'offrir une réduction de 20%. Vous auriez une règle d'entreprise dans votre BLL qui va quelque chose comme: xxx

0 commentaires

0
votes

Vous pouvez utiliser la conception suivante:

DAL:

namespace DAL.Repository
{
    public class UsersRepository
    {
        public static IList GetUser(string UserId)
        { 
            using(MyDBEntities context=new MyDBEntities())
            {
               // it calls SP in DB thru EF to fetch data
               //here you can also context.user to fetch data instead of SP
                return context.GetUser(UserId).ToList();

            }
        }
    }
}
BLL

namespace BLL
{
   public class User
    {
       public static IList GetUser(string UserId)
       {
           return DAL.Repository.UserRepository.GetUser(UserId);
       }
    }
}
PL

  ddlUser.DataTextField = "UserName";
  ddlUser.DataValueField = "UserId";
  ddlUser.DataSource= BLL.User.GetUser(string.Empty);
  ddlUser.DataBind()

0 commentaires