Mitglied "Is-A" Person oder Person "Has-A" Registrierung

Ich versuche, eine Reihe von Modellen für unsere Enterprise App zu erstellen. Sie wurden nie sehr eng an die Datenbanken gebunden. An dieser Stelle versuche ich einfach die Fragen "Is-A" oder "Has-A" zu beantworten. Ich stütze das von der DB-Struktur ab, aber ich möchte nicht notwendigerweise daran gebunden sein.Mitglied "Is-A" Person oder Person "Has-A" Registrierung

Für den Anfang habe ich die, sehr, offensichtliche Person Modell mit der typischen "Has-A" Telefon und Adresse. Fast alles funktioniert von diesem Personenmodell und ist ein "Has-A".

Allerdings haben wir Mitglieder. In unserem DB/Current System ist ein Mitglied eine Person, die eine Registrierung hat. Um eine Registrierung eines bestimmten Typs zu sein, der nicht angemeldet ist (von Datum).

Auf der einen Seite fühle ich, dass Mitglied Person als eine "Is-A" -Beziehung ererben würde. Aber ich bin sehr neu in dieser Art von Dingen und ich frage mich, ob ich darüber denke. Hat meine Person "Has-A" Einschreibung oder bedeutet das etwas anderes?

Es macht mich wundern, wenn ich ein Mitglied habe, sollte ich verschiedene "Is-A" -Modelle für Pre-Enrolments, Enrolments, Ehemalige Registrierungen? Es scheint eher eine Frage des Staates zu sein, aber auch hier bin ich neu. Wenn es eine Frage des Staates ist, bin ich zurück, um nur ein Personenmodell zu haben, das "Has-A" Enrollment hat?

Ich verstehe, das ist, etwas, Meinung basiert und ich begrüße die Meinung jeder Person zu diesem Thema.

Quelle

2012-04-11 Refracted Paladin

Enrollment klingt wie eine [Assoziationsklasse] (http://etutorials.org/Programming/UML/Chapter+6.+Class+ Diagramme + Advanced + Concepts/Association + Class /) (vor allem, da Sie mehrere Einschreibungen erwähnen - Pre, Former usw.). Was in diesem Fall fehlt, ist das "In was" der Einschreibung (z. B. ein Plan irgendeiner Art?). – Fuhrmanator

@Fuhrmanator: So klingt es wie Sie glauben, dass meine Personenklasse "hat-a" Einschreibung (en) mit der oben genannten "Association-Klasse" gegen mich mit einer Member-Klasse, die von meiner Person Klasse erbt ... Ich glaube, ich stimme zu. Ich werde das Konzept auf meine Modelle anwenden und sehen, wie es aussieht. Wie bei Ihrem verknüpften Beispiel haben die Registrierungen einen Datumsbereich, der Ihnen das Gefühl gibt, dass Sie kein Problem haben. –

Is-a macht keinen Sinn für mich, aus den gleichen Gründen, die @Alex Burtsev in seiner Antwort unten erwähnt. – Fuhrmanator

Es macht mehr Sinn, dass die Person höher in der Hierarchie ist. Aus der Gruppe aller Menschen haben Sie einige Mitglieder, einige Ex-Mitglieder und einige zukünftige Mitglieder.

Wenn Sie versuchen, es andersherum zu betrachten und sagen: Aus der Gruppe aller Mitglieder sind alle Menschen ... aber einige sind Dis-Enrolled? Es macht weniger Sinn, denn wenn sie abgeschrieben sind, dann sind sie nicht länger Mitglieder.

Es sei denn, ein Mitglied und Einschreibung sind nicht verbunden (dh. Wenn Sie sich abmelden können und noch Mitglied sein).

Quelle

2012-04-11 16:37:41

Zu Ihrer letzten Aussage, Nein, obwohl Sie Dinge im System haben können, die nur für ein Mitglied gelten könnten, obwohl Sie ein Mitglied sind, das sich nicht angemeldet hat. Deshalb fühlt es sich für mich fast wie ein "Zustand" an, aber was weiß ich, seit ich überhaupt fragen musste. –

Zu Ihrer ersten Aussage, vielleicht bin ich Missverständnis, aber ich denke auch, dass die Person höher sein sollte. Was ich fragen wollte, war, ob meine Person Anmeldungen haben sollte oder ob ich ein Mitglied haben sollte, das von einer Person mit Anmeldungen übernommen wurde. Zusätzlich frage ich mich, wie ich das ganze "Staat" Ding handhabe. Das macht mehr Sinn? –

Das wissen Sie bestimmt! Dies ist Ihr Programm nach allem. Wenige Fragen: 1) Können Sie mehrere Anmeldungen haben? 2) Können Sie mehrere Mitgliedschaften haben? Ich bin mir nicht sicher, wie Sie Staat verwalten würden, sollten Sie wahrscheinlich bestimmen, was Sie mit Mitgliedern/Registrierung zuerst tun möchten. –

Nun, ich werde versuchen, Ihre Frage zu beantworten, obwohl ich nicht ganz verstehe, was "Enrollment" ist (ich bin kein englischer Muttersprachler) Ich denke, es ist eine Art von Mitgliedschaft.

Angenommen, Sie entscheiden sich für die Verwendung der IS-A-Beziehung. Sie erhalten also: Mitglied: Person, VIPMitglied: Mitglied, Mitglied: Mitglied usw. Was würden Sie tun, wenn Sie ein Person-Objekt in Mitglied oder etwas ändern sonst? Sie müssen Ihr Objekt in diesen Typ konvertieren, ein Member-Objekt erstellen und Werte aus dem Person-Objekt kopieren, das ist eine Menge Vorarbeiten.

Wenn Objekt es ändert Geben Sie nach der Erstellung besser eine Eigenschaft ein, um den Typ zu unterscheiden. Cosider Apfel: Frucht (Apfel ist immer Frucht, kann nicht Tomate werden), und CanceledOrder: Auftrag (Auftrag kann CancledOrder werden, also würde ich Order.State bevorzugen). Dies gilt insbesondere für Sprachen, in denen das Objekt erst einmal erstellt werden kann (z. B. C#).

Wie für Ihren Fall von dem, was ich verstand ich schaffen würde:

public class Person 
{ 
    public IEnumerable<Membership> Memberships {get;} 

    public bool IsMember 
    { 
     get 
     { 
      return Memberships.Any(); 
      //Or what ever logic you imply 
     } 
    } 
}

Quelle

2012-04-11 19:24:46

Mitglied "Is-A" Person oder Person "Has-A" Registrierung

Antwort

Verwandte Themen