Implémentation d'un CRUD en utilisant une interface

Quelle est la meilleure approche pour mettre en place un CRUD sur le BL en utilisant l'interface qui sera utilisée pour résumé DAL opérations? J'ai besoin de vos avis les gars..

Voici mon projet..

Entités de données qui sont mappés dans la table de base de données

 public class Student
 {
    public string StudentId { get; set; }
    public string StudentName { get; set; }
    public Course StudentCourse { get; set; }
 }

 public class Course
 {
    public string CourseCode { get; set; }
    public string CourseDesc { get; set; }
 }

J'ai créé une Interface CRUD à l'abstrait de l'objet des opérations de

public interface IMaintanable<T>
{
   void Create(T obj);
   T Retrieve(string key);
   void Update(string key);
   void Delete(string key);
 }

Et puis un composant qui gère l'Entité et de ses opérations par la mise en œuvre de l'interface

public class StudentManager : IMaintainable<Student>
{
    public void Create(Student obj)
    {
        //inserts record in the DB via DAL
    }

    public Student Retrieve(string userId)
    {
        //retrieveds record from the DB via DAL
    }

    public void Update()
    {
        //should update the record in the DB
    }

    public void Delete(string userId)
    {
        //deletes record from the DB
    }
}

exemple d'utilisation

    public void Button_SaveStudent(Event args, object sender)
    {
        Student student = new Student()
        {
           StudentId = "1", StudentName = "Cnillincy"
        }

        new StudentManager().Create(student);   
     }

comme vous pouvez le voir, il y a une anomalie au niveau de la méthode de mise à jour

    public void Update()
    {
        //should update the record in the DB
    }

ce qui devrait cette méthode pour mettre à jour les objets de la propriété? dois-je hériter de la Étudiant?

    public class StudentManager : Student , IMaintainable<Student>
    {
        public void Update()
        {
            //update record via DAL
         }
    }


    public void Button_SaveStudent(Event args, object sender)
    {
        Student student = new StudentManager();
        student.StudentId = "1";
        student.StudentName = "Cnillincy"
        student.Update()
    }

Ou devrais-je simplement contenir les Élèves de la classe comme un attribut de l'Étudiant manager?

     public class StudentManager : IMaintainable<Student>
    {
        public Student student { get; private set };

        public void Create() {}
        public void Update() {}
        public void Retrieve() {}
        public void Delete() {}
    }

Qui plus appropriée? Ce sujet de l'interface? Toutes les autres suggestions les gars? merci..C

source d'informationauteur CSharpNoob

  1. 14

    Votre interface CRUD doit probablement ressembler à

    public interface IMaintanable<T>
{
    string Create(T obj);
    T Retrieve(string key);
    void Update(T obj);
    void Delete(string key);
}

    qui est, à la fois Create et Update prendre une copie de l'objet que vous voulez mettre à jour. La différence est que le Update pouvez obtenir le key de la objafin qu'il sache objet, il est en train de changer. Create serait normalement entraîner la clé pour être créé afin de passer en tant que valeur de retour. Espérons que cela aide.

    (La mise à Jour peut également transmettre la clé).

  2. 9

    Personnellement, je pense que tout ce que vous manquer, c'est la terminologie appropriée. Ce que c'est vraiment une approximation d'un très utile modèle, appelé modèle de référentiel. Autant que le type de la conscience, va, la mise en œuvre devait être considéré comme un générique référentiel.

    La façon dont j'ai personnellement mis en œuvre dans le passé a été d'avoir une interface qui définit le référentiel, comme IRepository<T>et une classe de base qui est spécifique au type de dépôt, comme un SqlRepositoryBase<T>. La raison que je ferais c'est que je peux mettre de la mise en œuvre du code spécifique dans la classe de base. Ainsi, la plomberie est fait et je peux vous soucier de domaine spécifique à la mise en œuvre dans le dépôt définitif, qui serait StudentRepositoryun SqlRepository<Student> (ou SqlRepository<IStudent> si vous définir des interfaces pour votre entité).

    Il me semble que vous êtes préoccupé par la façon dont de nombreux objets sont instansiated, et je peux vous dire que vous n'êtes pas de la génération d'un assez importante ponction sur les ressources à être vraiment inquiète de la mise en œuvre de cette manière. Old-timers pourraient grincer des dents à la réalité, mais nous ne sommes pas en essayant d'optimiser la RAM de 64 ko ou plus. 😉 C'est plus sur la facilité de maintenance, contrats de code, etc.

    De ne pas ajouter inutiles complexité, mais vous aussi, vous voudrez peut-être regarder dans l'Unité de Travail de Motif si vous êtes à la recherche lors de l'inscription de plusieurs entités de différents types dans les transactions atomiques.

    Ici sont un couple de bonnes références pour ces sujets:

    Deux plats à emporter à partir de ce en général (à mon humble avis):

    • Je suis personnellement en désaccord avec l'hypothèse qu'un modèle de Référentiel démarche n'a d'utilité dans les grands projets, en particulier pour les Génériques modèle de Référentiel. Si vous commencez à placer ce type de code dans une bibliothèque réutilisable, vous serez surpris comment rapidement vous pouvez commencer à créer une ressource inestimable de blocs de construction.

    • Le plus gros plus de cette approche est la quantité de testabilité de, même plus que la réutilisabilité. Si vous êtes à la recherche pour se moquer de vos dépôts de toute sorte d'une approche TDD, vous pouvez le faire avec peu d'effort. Cela vous permettra d'écrire plus riche des tests autour des usages des dépôts tout au long de votre code.

  3. 2

    Je l'ai vu de Rob Conery que j'aime vraiment. Sa puissance réside dans la flexibilité des arguments que vous pouvez passer à l'méthodes. Votre implémentation n'est pas suffisamment robuste de l'OMI. Découvrez son MVC de kit de démarreur d'ici http://mvcstarter.codeplex.com/ (On appelle ISession).

    public interface IMaintainable : IDisposable
    {
       T Single<T>(Expression<Func<T, bool>> expression) where T : class, new();
       System.Linq.IQueryable<T> All<T>() where T : class, new();
       void Add<T>(T item) where T : class, new();
       void Update<T>(T item) where T : class, new();
       void Delete<T>(T item) where T : class, new();
       void Delete<T>(Expression<Func<T, bool>> expression) where T : class, new();
       void DeleteAll<T>() where T : class, IEntity, new();
       void CommitChanges();
    }
  4. 0

    Je ne voudrais pas faire StudentManager hériter Étudiant, je voudrais faire de ma mise à Jour de la méthode apatrides comme votre méthode de création, c'est à dire

    public interface IMaintanable<T>
{
  void Create(T obj);
  T Retrieve(string key);
  void Update(T obj);
  void Delete(string key);
}

    et

    public void Update(T obj)
{
  //should update the record in the DB
}
  5. 0

    Prendre un coup d'oeil à la nouvelle Entity Framework 4 qui a été publié récemment. Ils sont doté d'un "code" par convention" modèle qui vous permet de mapper les objets directement à la base de données sans avoir à se soucier d'un DAL.

    "Gu" a une superbe série décrivant comment il est facile de cartographier vos objets, et même faire quelques simples modifications lors de la liaison à la base de données par le biais de la DbContext modèle qu'il utilise.

    Il est intéressant de noter que la version actuelle est à CTP4, mais je prévois que la plupart des questions ont déjà été élaborés avec le cadre et devraient bien vous servir.

  6. 0

    J'ai changé les réponses ici un peu, à présent:

    public interface IMaintanable<T>
{
    Guid Create(T obj);
    T Read(Guid key);
    bool Update(T obj);
    bool Delete(Guid key);
}

    Cette interface est basée sur ma structure de base de données. J'utilise le Guid pour les clés primaires.