J'ai besoin de chercher un "client" dans un db, ce qui serait un bon design ici?

Question

Nous sommes un couple d'étudiants qui tentent d'implémenter un design pour rechercher des informations client dans une base de données. Lorsque la classe GUI demande un client avec le nom de famille "Jensen", une classe de clients crée-t-elle alors de nombreux objets pour chaque client avec ce nom, donne tous ces objets à la classe GUI, laisse la classe GUI changer quelque chose ou ajouter quelque chose, puis utilisez une méthode dans la classe client pour le mettre à jour dans la base de données?

Customer class: 
    Surname 
    Email 

getSurname() 
setSurname() 

static List getCustomerFromDb(surname, email): 
    Customer customer = new Customer() 
    customer.setSurname(surname from db) 
    .. 
    .. 
    return listOfCustomers 

updateThisCustomerInDb(): 
    //updates all fields in db 

Notre application est maintenant que nous envoyons un ResultSet à l'interface graphique de classe à partir d'une méthode statique dans le client à la recherche de clients .. Et si l'interface graphique de classe veulent changer un champ comme le courrier électronique dans le client , il envoie un HasMap avec les clés et les valeurs à changer.

N'est-il pas mauvais de créer 300 objets clients et de n'en avoir besoin que d'un seul? La raison pour laquelle nous demandons de l'aide, c'est que nous avons entendu dire que c'est une mauvaise conception OO de ne pas mettre à jour, modifier, trouver (dans la base de données) des clients utilisant des objets, mais en utilisant ResultSets et HasMaps.

Merci =)

Answer 1

Si l'on suppose qu'un ORM-cadre comme Hibernate est soit surpuissant ou non autorisé pour votre mission est ce que je propose:

Mettre en oeuvre le modèle de conception DAO. En un mot, cela signifie que vous déclarez une interface avec des méthodes pour récupérer et modifier les données de la base de données. Leurs signatures doivent ressembler à l'exemple de code que vous avez fourni et doivent renvoyer des objets Domaine, c'est-à-dire des objets qui ne sont pas spécifiques à l'implémentation du code d'accès à la base de données. Un objet de domaine typique pour le client pourrait ressembler à ceci:

public class Customer { 

    private String surname; 
    private String email; 
    private long id; 

    public String getSurname() { 
     return surname; 
    } 
    public void setSurname(String surname) { 
     this.surname = surname; 
    } 
    public String getEmail() { 
     return email; 
    } 
    public void setEmail(String email) { 
     this.email = email; 
    } 
    public long getId() { 
     return id; 
    } 
    public void setId(long id) { 
     this.id = id; 
    } 

} 

Ensuite, créez une implémentation de l'interface où tout le code spécifique DB-graveleux est placé.Ce qui vous a été dit au sujet de la mauvaise conception me semble correct, vous ne voulez pas exposer le code spécifique à la db dans les couches supérieures de votre conception. Vous devez utiliser vos propres objets ou collections d'objets spécifiques au domaine.

Bonne chance

Answer 2

Vous pouvez modifier le processus un peu, faites votre recherche et retourner des résultats de recherche qui permettent à l'utilisateur de sélectionner le client à modifier, comme Kobi a dit le client doit avoir un identifiant unique, Une fois que vous avez cela, vous pouvez obtenir seulement l'objet client unique que vous souhaitez travailler avec.

Espérons que cela aide.

Chris

Answer 3

<speculation>
je suis un développeur .net, mais je suis sûr que si le ResultSet contient l'ensemble des données qu'il contient également 300 objets (comme les lignes?) - il n'y a pas moyen de contourner cela. D'ailleurs, 300 est considéré comme un petit nombre, mais si vous renvoyez des lignes dont vous n'avez absolument pas besoin, vous pourriez avoir des problèmes d'échelle, quand vous avez un million de fois plus d'enregistrements (donner ou prendre). À long terme, il est préférable de renvoyer vos propres classes et de les utiliser entre la couche d'accès aux données et la couche de présentation. Cela vous évitera de dupliquer le code. En fait, l'interface graphique ne devrait pas contenir ce code, et il est préférable que ces couches ne relaient pas directement sur la structure des tables et des noms de colonnes (car cela devient compliqué).
Créer vos propres classes et les utiliser est commun et conseillé. Il a également amélioré la fiabilité et la maintenabilité de votre code - cela peut ne pas intéresser le collage, mais considéré par certains comme étant plus important pour la vitesse ou l'utilisation de la mémoire.

Answer 4

Votre code ne doit pas tenir sur chaque enregistrement dans une base de données quand il n'a pas besoin. Que se passerait-il si vous aviez 50 000 000 de clients dans votre base de données?

Utilisez votre base de données! Si vous savez exactement quels objets vous voulez, écrivez une requête pour renvoyer uniquement ces objets dans une liste. Si vous savez exactement quelles lignes vous souhaitez mettre à jour sans les voir d'abord, alors écrivez une requête pour mettre à jour uniquement les lignes pertinentes directement dans la base de données sans retourner le jeu de résultats.

Désolé, ce n'est pas pertinent pour votre question.

Answer 5

Je vois ici deux options:

1. Il y a 300 clients nommés Jensen et que vous voulez les présenter à l'utilisateur final
2. Il y a 1 client nommé Jensen et 299 autres clients

Dans le premier cas, il est OK de créer 300 objets de clients et de modifier seulement un - utilisateur a recherché un gars nommé Jensen et il y avait 300 d'entre eux. En second lieu, vous devez créer un seul objet et l'utiliser dans l'interface graphique.

De plus, il est également judicieux de séparer le code DB (transformation des ResultSets en objets) de l'interface graphique. L'idée avec le modèle DAO est justifiée ici.

it helps

EDIT: entrez trop tôt pressé