2011-03-08 6 views
0

J'utilise LINQ to SQL, 3.5 Framework et je voudrais savoir quelle est la meilleure façon de concevoir les classes. Prenons un exemple très simple du tableau User.
Si j'ai une table utilisateur avec 3 rôles différents de client, administrateur, caissier. Je dirais que je vais devoir créer 3 classes pour chacun des rôles. par exemple. customers.cs ...comment concevoir les classes

Question:
1) Depuis Linq .dbml a déjà l'auto généré par l'utilisateur à partir de ma table utilisateur, toutes les propriétés sont déjà prédéfinies, dois-je encore besoin de créer une classe à User.cs être hérité par 3 des rôles de classe ci-dessus? C'est parce que je ne peux pas ajouter de propriétés en double dans le fichier User.cs, par exemple. Public string Name {get;set;} aurait échoué car dans le .dbml a déjà l'appel de propriété Nom.

2) Cette question sera très élémentaire je pense ... mais je trouve utile si je peux connaître la bonne réponse. Comment dois-je garer ma fonctionnalité dans la bonne classe? e.g. PrintYearlyReport(), CheckStaffSalary(), ModifySale(), UpdateGovernmentTax() .... toutes ces fonctions sont sous le rôle d'Admin. Ce sera très lisible si nous avons admin.PrintYearlyReport(), admin.ModifySale() ... Cependant, si nous gardons toutes les fonctionnalités de l'administrateur dans le fichier Admin.cs, alors ce fichier serait très très énorme !!! Pour des raisons de POO, nous devons avoir des classes comme par ex. Sale.cs, Payment.cs, Invoice.cs. Si nous divisons toutes ces fonctionnalités dans chaque classes différentes, alors nous n'aurons plus la façon élégante d'appeler la admin.PrintYearlyReport() plus ..

+0

BTW, qu'est-ce que UML a à faire avec votre question? –

+0

J'ai utilisé UML pour dessiner toutes les classes avant de commencer le codage. Félicitations – VeecoTech

+0

, mais comment cela change-t-il votre question? Demandez-vous comment concevoir les classes ou comment créer un modèle de classe UML? –

Répondre

0
  1. Vous pouvez créer des sous-classes de la classe utilisateur, à savoir , Customer, Admin et Cashier, puis spécifiez la classe correcte en fonction du rôle de l'utilisateur. Parfois, nous concevons en créant une méthode comme User.IsInRole ou User.HasAccessTo méthodes que vous pouvez appeler pour vérifier qu'ils peuvent accéder ou utiliser certaines fonctionnalités.

  2. Vous pouvez diviser la fonctionnalité en fichiers séparés tout en les conservant dans la même classe en utilisant les classes partial. Si vous définissez public partial class Admin, vous pouvez définir la classe Admin en autant de fichiers distincts que vous le souhaitez et toutes les propriétés seront ajoutées lors de la construction du projet.

+0

Pour 2) Si disons que j'ai le fichier Sale.cs dont je veux garer les fonctionnalités de l'administrateur en elle. Dans le sale.cs devrait avoir cette «vente partielle de classe publique». Voulez-vous dire que je devrais hériter de l'admin comme ceci «public partiel classe Sale: Admin»? – VeecoTech

+0

Si vous souhaitez que toutes les fonctionnalités soient "élégantes", ce qui signifie que vous pouvez accéder à toutes les méthodes du même objet, alors vous voulez utiliser 'public partial class Admin' en haut de chaque classe. Même si elle s'appelle 'Sale.cs', vous pouvez toujours l'intégrer à la classe' Admin' et l'utiliser pour séparer les fonctionnalités liées spécifiquement aux ventes. C'est un modèle que j'utilise régulièrement dans mes propres projets. Puis quand vous allez taper 'admin.' et obtenir une liste de méthodes, ils seront tous ensemble. – mellamokb

+0

Pourriez-vous me trouver un échantillon pour cela en ligne, je ne semble pas obtenir le bon mot-clé pour rechercher ce type de tutoriel – VeecoTech

0

Gardons les choses simples. Habituellement, la meilleure réponse est la plus simple. Avez-vous besoin d'avoir plus d'un cours? Peut-être peut-être pas. Si les différences entre les rôles sont simples, alors pourquoi le besoin de créer des sous-classes? Je commence habituellement avec une classe et comme le comportement est mieux défini et que vous pouvez clairement différencier les sous-classes que vous ne les créez. Cela dit, vous devriez penser à ce que vous voulez que vos objets ressemblent, et par là je veux dire quelles dépendances vous créer et quelles fonctionnalités seront partagées. Composition vs héritage Quand je pense aux utilisateurs et aux rôles je pense: l'utilisateur a le rôle x, pas l'utilisateur est le rôle x parce que les rôles peuvent changer. Les fonctionnalités et propriétés communes doivent être dans une classe de base. Peut-être que vous pouvez mettre vos règles d'accès dans une classe qui vit au sein de l'utilisateur:

User{ 
    Name 
    Role 
    Rules{ } 
} 

On peut donc dire

if(user123.Rules.CanPrint()) 
{ 
Print(); 
} 

Créer les règles à l'intérieur de l'utilisateur et de passer dans le rôle (s) afin la classe rules peut comprendre ce que cet utilisateur peut faire. C'est comme ça que je le ferais. Mon point est, n'obtenez pas la gueule de bois sur quelle classe devrait aller où. Définissez les objets et le comportement et laissez les classes se définir elles-mêmes. Vous apprendrez à repérer quand une classe devient trop grande et a besoin de breake up.

0

Vous pouvez ajouter un stéréotype à votre diagramme de classe et obtenir des annotations de persistance en direct dans votre code java. Si vous utilisez Hibernate, vous pouvez obtenir votre base de données à partir de votre code. Pas besoin de créer un modèle UML objet et un autre modèle pour votre base de données. C'est ce que je fais et vraiment cool !!

Cela fonctionne uniquement avec Java et pas avec C#.

Questions connexes