lbm1305

Es würde über eine lokale Datenbankdatei (*.sdf) funktionieren, dafür muss aber der SQL-Server 2005 Express installiert sein.

Hast Du schonmal einen Datentyp in einer Klasse deklariert bzw. instanziert? Integer, String, Double etc? Eine Klasse ist nichts anderes als ein Datentyp, nur selbst definiert. Möglich wäre hier noch, die Instanz des Objects über den Konstruktor in die zweite Klasse zu geben.

Indem die Klasse Kantine entweder eine Instanz oder eine Collection vom Typ Gericht kapselt.

Eine Möglichkeit wäre Dependency Injection. Frameworks wären u.a. hier: Unity, Windsor Castle, Spring.NET

Normalisierung (Datenbank) ? Wikipedia Siehe 1.-3. Normalform

Wo ist den nun der Lerneffekt für den Themenersteller?

Hmm...eventuell sollte man der Datenbank auch mitteilen, dass was gelöscht wurde?! Wie hältst du die Daten aus der DB im Speicher? DataSet / DataTable oder Listen?

Ein Passwort in der Registry? Huuaaahhh Mittlerweile geht man wieder davon weg, irgend welche Informationen in die Registry zu schreiben. auch wegen möglichen Admin-Kennwortabfragen.

Ein Buch für Anfänger kann ich nicht empfehlen. Es gibt aber sicherlich ein paar Tutorials zum Thema XML. Eventuell ein paar kleine Beispiele suchen und mal nach programmieren, auch wenn man diese eigentlich kopieren könnte.

Die Xml Datei kannst Du a) über einen externen Editor erstellen und da bereits bekannte Strings eintragen oder du lässt, wenn die Datei noch nicht exisitiert, diese von Deinem Programm erstellen. Zum Einlesen der Datei muss dem Programm der Pfad bekannt sein. Daher wäre es ratsam, diese Datei in Dein Programmverzeichnis zu legen. Es ist Dir überlassen, ob Du in diese Datei nur den ConnectionString schreiben lässt oder noch anderes Zeug, was gespeichert werden sollte. Du kannst auch alle Daten der Datenbanken in Xml ausgeben lassen. Dann bräuchtest Du keine Datenbank mehr ;-)

Alles was in die (Xml)Datei geschrieben wird, bleibt auch da. Außer die Datei wird von Hand überschrieben. Auch das Speichern der ConnectionStrings in einer Datenbank wäre möglich. Diesen Weg finde ich persönlich nicht soo doll. :-) Hier wäre ein Beispiel für das Erstellen einer Xml Datei. Dies ist aber in C# geschrieben, wobei die Klassenbezeichnungen im .NET gleich sind. VB.NET hat halt nur ne andere Syntax. CSharp XML - Erzeugen eines XML-Dokuments mit C#. / XmlDocument XmlNode CreateElement AppendChild

Andere Frage: Ist es sinnvoll, Resourcen zu verschwenden, die möglicherweise nicht benutzt werden?

Der Benutzer gibt doch die Zugriffsdaten für die Datenbank ein bzw. diesen müssen doch, bevor die Datenbank im DBMS angelegt wird, feststehen. Denn sonst könnte ja keine DB angelegt werden. Das Xml-Attribut "name" sollte im Grunde genommen nur eine Art Key sein, um den ConnectionString zu identifizieren. Nach der Eingabe muss der User doch irgendwas klicken?! Auf diesen Klick schreibt eine andere Klasse den eingegebenen String in die XML-Datei.

Naja...einfacher ist vielleicht übertrieben. Ich finde es aber komfortabler. Die Struktur der Xml Datei köntte so aussehen: <?xml version="1.0" encoding="utf-8"?> <Datenbanken> <Datenbank name="Database1"> <connectionString>Hier steht der ConnectionString zur Database1</connectionString> </Datenbank> <Datenbank name="Database2"> <connectioNString>Hier steht der ConnectionString zur Database2</connectioNString> </Datenbank> </Datenbanken> Sollte nun etwas hinzugefügt werden, dann wird unter dem Database2-Element ein weiteres eingefügt.

Ich würde den Weg über eine XML Datei gehen, in der sämtliche Strings abgelegt werden. Den entsprechenden String kann man sich dann über ein Key zurück geben lassen.

Auch nicht ganz korrekt. Der Methodekopf müsste dann so aussehen. IFoo.IEnumerable<int> LOadCollection()

Stimmt. Hatte ich übersehen. Es war eher so gedacht, dass die Klasse Foo noch ein Interface IFoo bzw. die Methode explizit implementiert. sicherlich würde es reichen private IEnumerable<int> LoadCollection() { return Enumerable.Range(1,100); }

Rückgabe eines Objekts, welches das generische Interface IEnumerable<T> implementiert!? warum eine Methode? Weil dann die Möglichkeit bestände, die Methode LoadCollection() explizit von einem möglich Interface IFoo zu implementieren.

In der Designer.cs soll man auch nicht rumvorwerken. Entweder Du machst eine Partial Class und steckst alle EventHandler da rein oder eben in die Klasse, wo der Handler benötigt wird.

ExecuteNonQuery liefert eine DataReader Objekt zurück. Dieses muss dann durchlaufen werden. Dann kommst Du auch an die Daten. Das die Onlinerecherche nichts bringt, halte ich für ein Gerücht. Wenn man ordentliche Suchbegriffe eingibt, erhält man mehr als ein Resultat.

Sicher... ;-)

public class Foo { // Private Fields private IEnumerable<int> _internalList; // Methods private IEnumerable<int> LoadCollection() { _internalList = Enumerable.Range(1, 100); return _internalList; } // Properties public IEnumerable<int> Zahlen { get { if ( _internalList == null ) _internalList = LoadCollection(); return _internalList; } } }

Das Property ist nicht für den Inhalt der Liste zuständig, sondern das Property repräsentiert die Liste selber. Auch wenn das List-Property nur einen Getter hat, sind die die Methoden der Liste voll verfügbar. In diesem Fall (Setter fehlt oder ist private) kann ich dem Objekt keine neue Liste hinzufügen bzw. die bestehende ändern. Meistens werden Collections aber aus dem Objekt heraus erstellt. Der Getter gibt diese halt nur nach außen ab.

Ich muss die Frage korrigieren. Wozu brauche ich einen (öffentlichentlichen) Setter, wenn ich nur eine Liste zurückgeben möchte?

Ich antworte mal mit einer Gegenfrage. Wozu soll der öffentliche Setter gut sein?