Laden...

Entwicklung in Schichten

Erstellt von Martin Weber vor 19 Jahren Letzter Beitrag vor 18 Jahren 6.139 Views
Martin Weber Themenstarter:in
21 Beiträge seit 2004
vor 19 Jahren
Entwicklung in Schichten

Ahoi,

ich habe letztens in einem interessanten Online-Artikel der dotnetpro gelesen das Entwicklung von Applikationen in Schichten eine geniale Sache sein soll. (Presentation-, Business Logic-, Data Access- und Data Storage Layer).
Diese Information war mir nicht ganz neu, jedoch habe ich mich nie wirklich damit beschäftigt mir diese Materie näher zu bringen. Die Vorteile sind jedoch nicht von der Hand zu weisen. Daher bin ich sehr interessiert.

Ich würde nun gerne wissen, wie man diese verschiedenen Schichten code-technisch realisiert. Wird jede Schicht durch ein eigenes Objekt repräsentiert, oder wie kann ich mir das vorstellen?
Falls jemand interessante Quellen zur Vertiefung und evtl. Codesnippets zum besseren Verständnis für mich hat, wäre ich sehr dankbar.

4.207 Beiträge seit 2003
vor 19 Jahren

svn://mywindowsserver.de/netug-kl.de

und

svn://mywindowsserver.de/golohaas-blog.de

In beiden Fällen brauchst Du Subversion, um darauf zugreifen zu können. Die laufende Webseite siehst Du jeweils unter http://www.netug-kl.de und http://www.golohaas-blog.de ...

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

F
722 Beiträge seit 2005
vor 19 Jahren

Hi,

codetechnisch empfiehlt es sich, die einzelnen schichten in assemblies zu kapseln. angenommen, du hast eine web anwendung entwickelt, die geschäftslogik aber in einer eigenen dll implementiert, so wird es kein problem sein, die präsentationsschicht auszutauschen, also z.b. von der web-anwendung zur win-forms-anwendung zu wechseln. analog verhält es sich dann mit allen anderen schichten, z.b. könntest du auf der persistenzschicht mal locker von der datenbank auf ein eigenes dateiformat oder so wechseln und müsstest dann anstatt der gesamten anwendung nur den Data Access Layer ändern.

im internet hab ich grad nich so sonderlich interessante sachen zu dem thema gefunden, aber hier geht es im grunde um software architektur, aber auch um projektmanagement, denn diese konzepte kommen vor allem in komplexen software systemen zum einsatz.

zu den beiden themen gibt es bücher wie sand am meer, also einfach mal amazon und terrashop checken =)

beste grüße,

f.

Martin Weber Themenstarter:in
21 Beiträge seit 2004
vor 19 Jahren

@Golohaas.de
Genial, das war genau das was ich gebraucht habe. Habe etwas über dem Code gebrütet und mir ist sofort vieles klar geworden.
Aber ein paar Fragen habe ich noch.

  1. Was bedeutet DAHC und BPHC?
  2. Wenn ich an einer Embedded Resource (hier die XML mit den Querys) durchgeführt habe, dann muss ich immer in VS.NET die XML zurückschalten auf "Content", dann compilieren und die XML wieder auf Embedded Ressource umstellen + compilieren. Sonst werden die Änderungen nicht übernommen.
    Gibts da nen bequemeren Weg?

@feadur
Vielen Dank fü die Tipps. Evtl. lege ich mir auch mal nen Buch zu dem Thema zu.

E
63 Beiträge seit 2003
vor 19 Jahren

zum thema trennung in schichten, kann ich jedem nur
http://www.ormapper.net/
empfehlen.
das ganze kostet zwar 50$. man bekommt jedoch
ein riesen paket mit quellcode und unbegrenzte updates.

der ormapper versteckt die komplette datenhaltungslogik
hinter c# objekten, so dass man in 80% der faellen gar nicht
merkt, dass man mit einer datenbank arbeitet.
zudem ist ein tool enthalten, dass die notwendigen
klassen (die die tabellen abbilden) generiert.

das ganze ist wahrscheinlich nichts fuer leute die nur kleine
sachen machen (dafuer wohl zu teuer 😉).

N
4.644 Beiträge seit 2004
vor 19 Jahren

Original von entelechie
zum thema trennung in schichten, kann ich jedem nur

>

empfehlen.

Dem kann ich zustimmen. Ich arbeite auch gerade mit diesem Mapper an einem großen Projekt.

4.207 Beiträge seit 2003
vor 19 Jahren

DAHC = Data Access Helper Component
BPHC = Business Process Helper Component

Wegen der XML-Dateien ... wüsste ich im Moment auch keinen bequemeren Weg.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

T
108 Beiträge seit 2005
vor 18 Jahren

Hallo!

Ich habe meine Anwendung auf eine 3-Tier Architektur umgebaut.
Um Den Code "sauber" zu halten, habe ich die SQL-Statements in einem XML-File hinterlegt.

Nun bleibt aber folgende Frage: "Wie kann ich es verhindern, das ein Benutzer der Anwendung einfach die SQL-Statements im XML File manipuliert!?"

Ich hoffe, dass jemand eine Idee hat, um eine Manipulation zu verhindern.

Gruß
Tokka

Was einmal war, wird nie wieder sein...

N
4.644 Beiträge seit 2004
vor 18 Jahren

Original von Tokka
Ich hoffe, dass jemand eine Idee hat, um eine Manipulation zu verhindern.

Du hast ja sicherlich einen DAL geschrieben. Warum bringst Du die SQL Queries nicht da unter?

T
108 Beiträge seit 2005
vor 18 Jahren

ich fand die Idee mit dem Auslagern der Queries in ein XML-File ganze nett 😁

Was einmal war, wird nie wieder sein...

P
939 Beiträge seit 2003
vor 18 Jahren

Hi Tokka,

es ist doch eine 3-Tier Anwendung. Wie soll der Benutzer der Middletier denn an die Xml-Files rankommen? Der Zugriff erfolgt doch remote oder nicht? Selbst wenn nicht, sehe ich da kein grosses Problem. Wenn die Anwendung lokal läuft, kann der Benutzer sowieso alles machen was er will. Die Datenbank wird dann auch lokal laufen. Wer stellt schon eine Datenbank öffentlich ins Netz? Und wenn sie lokal läuft, kommt man ohnehin ran. (Ansonsten schildere nochmal dein befürchtetes Szenario. Wahrscheinlich habe ich so einiges nicht richtig bedacht.)

Übrigens der Java O/R-Mapper Hibernate verwendet dieses Prinzip. Das Klassen- zu Tabellen-Mapping wird in Xml-Dateien angegeben. Zusätzlich können auch die Queries zu einer Klasse in der Datei abgelegt werden. Im Code sagt man dann nur noch "GetNamedQuery", setzt die Parameter und schickt ab. Echt vorteilhaft dabei ist auch, dass die Queries angepasst werden können, ohne am Code etwas ändern zu müssen. Einfach mit einem Texteditor editieren und fertig.

Also ich würde es so lassen,

Gruss
Pulpapex

T
108 Beiträge seit 2005
vor 18 Jahren

Moin!

Also normalerweise sollte das kein Prolblem sein, da das Middle-Tier auf dem Application Server liegt und der Zugriff vom Client remote erfolgt.

Ich habe nun das Problem, das es bei meinem Auftraggeber keinen Application Server gibt, sondern nur eine Maschine wo MS-SBS drauf läuft. Deshalb hatte ich überlegt, ob ich ggf das Middel-Tier mit auf dem Client hinterlege.
Es ist keine saubere und ordentliche Lösung, aber es geht in der Firma momentan nicht anders.

Ich werde aber wohl in diesem Fall die Queries in einer Klasse hinterlegen....

Danke für Eure Anregungen 🙂

Gruß
Tokka

Was einmal war, wird nie wieder sein...

3.728 Beiträge seit 2005
vor 18 Jahren
Remoting

Hi,

Du könntest Dir auch einen .NET Remoting Host bauen und Deine Geschäftslogik dort ablaufen lassen. Den Host kannst Du z.B. auf dem SBS Server laufen lassen, wenn kein separater PC dafür zur verfügung steht. Natürlich muss das .NET Framework dort installiert werden. Das sollte aber kein problem sein.

K
597 Beiträge seit 2005
vor 18 Jahren

Hallo entelechie,

ich versuch herauszufinden welcher OR-Mapper
für meine zukünftigen Projekte besser passt.

Du schwörst auf "http://www.ormapper.net/"
Ist Dir etwas aufgefallen was er nicht kann im vergleich
zu anderen Mappern?

Ich liebäugle eher zu Vanatec OpenAccess.NET Mapper
Obwohl ich noch keine Gelegenheit hatte das Teil zu testen.
(Mir fehlt die passende framework 2.0 version)
Was mit gefehlt ist, die gleiche API wie vom großen
Bruder der OO-Datenbank, deutscher Support und relativ Bezahlbar
etwa 600€

Gruß Kostas

N
4.644 Beiträge seit 2004
vor 18 Jahren

Kannst ja auch mal den OPF3 anschauen, den setzen wir ein.

K
597 Beiträge seit 2005
vor 18 Jahren

Hallo Noodles,

das gemeine ist, als Anfänger kann man sich sicherlich
mehrere Tools ansehen, beurteilen ob sie passen oder
nicht, ist durch fehlendes Hintergrundwissen leider nicht möglich.

Was ich durch die Tutorials gesehen habe ist, es ist
Attribute gesteuert.

z.B.: Die Field definition ist für mich schön selbsterklärend.
OpenAccess macht diese dinge in einem XML-File
(wenn ich das richtig verstanden habe)

Auf dem ersten Blick als Anfänger würde ich sagen: 👍



[Field("ID", AllowDBNull = false, Identifier = true, AutoNumber = true)]
public long ID
{
       get { return _id; }

       private set { _id = value; }
}



Sag mir lieber nicht was gut ist an diesem Produkt ist,
sonder eher was schlecht ist oder Fehlt. 😉

Gruß Kostas

N
4.644 Beiträge seit 2004
vor 18 Jahren

Bis jetzt habe ich noch nichts schlechtes an diesem Mapper gefunden.

I
1.739 Beiträge seit 2005
vor 18 Jahren

@Tokka
Die Auslagerung der SQL-Statements aus dem Code ist generell eine gute Idee(Wartbarkeit). Manipulation lässt sich durch Hashes ausschliessen, Lesbarkeit durch mehr oder weniger starke Verschlüsselung(ich empfehle dafür leichtere Varianten(Verhältnis von Zweck : Performance). Abzuwägen wäre Pro und Contra von Queries in Form von Clientseitigen SQL oder Stored Procedures.

Ansonsten: OR-Mapper und so:
-betrifft nur ein Schicht/dh. es sind mehr oder minder nützliche Hilfen zur Entkoppelung im sowieso vorhanden DAL(Wenn 3 oder n-Schichten), sie ersetzen kein Modell. Ohne OR-Mapper ist es natürlich aufwändiger..
-Abhängigkeiten(mind. eine zusätzliche durch den Hersteller(selbst bei Erhalt der Sourcen nicht unwesentlich))

K
597 Beiträge seit 2005
vor 18 Jahren

Hi ikaros,

die Sache mit der Abhängigkeit ist mir ebenfalls ein Dorn im Auge.
Unter Delphi habe ich schon des öfteren Blut spucken müssen.
Aber wir wollen schließlich produktiv Arbeiten sprich Geld verdienen.
Eine gewisse Investition ist sicherlich angebracht.
Das große Problem was jeder Anfänger so gut wie irgend möglich
meistern muss ist, zukunftsorientierte Komponenten mit ausreihender
Funktionalität mit ins Boot zu nehmen.
Die Zeitersparnis mit den OR-Mappern ist nur dann gegeben
wenn OO Programmiert wird. Wenn es um reine Datenbankanwendungen
geht, ist es auch möglich z.B.: ein Form für die Adressverwaltung
zu nehmen, Grids und Textboxes mit irgendwelche Dataset zu binden
und fertig. Die Adressen können auch ohne Objekte verwaltet werden.
Selbt wenn 3 oder n-Schichten angewendet wird gibt es kein zwingengen
Grund für OO. Ich habe zum lernen eine DAL-Dll erzeugt welche
Datasets zurückgibt diese brauche ich einfach nur mit den
Datensensitiven Komponenten zu binden.

Aber, ich habe noch keine Klasse selbst geschrieben möglicherweise liege
ich da falsch.

Darf ich euch noch ganz leise bitten meinen thread zu besuchen.
Ich hänge da noch ein bischen. Danke. 🙂

Master/Detail wie Detail aktualisieren?

Gruß Kostas

N
4.644 Beiträge seit 2004
vor 18 Jahren

Es gibt auch noch den Mapper von Wilson, der macht das Mappping aber auch über ein XML-File, was ich unschön finde.
Hast Du Dich schon für einen entschieden?

K
597 Beiträge seit 2005
vor 18 Jahren

Hallo Noodles,

falls Du mich meinst, nein, ich habe mich noch nicht entschieden.
Aber ich tendiere eher zu Vanatec OpenAccess.NET als
zweiter Favorit gilt NDO.
Als Grieche muß ich doch die Deutsche Wirtschaft
unterstützen. 😉
Ich werde mich erst nach der persistenceday Veranstaltung
endgültig entscheiden. Da erhoffe ich mir mehr Hintergrund-
Wissen zu ergattern.

Erfahrungsaustausch mit diesen oder anderen wie z.b. Wilson
oder OPF3 währe sicherlich sehr nützlich.

... Hallo Leute was verwendet Ihr für OR-Mapper?

Gruß Kostas

C
64 Beiträge seit 2005
vor 18 Jahren

Hallo,

also ich hab mir mal nhibernate angeschaut, fand aber das XML Mapping nicht so toll. Im momentanen Projekt arbeite ich mit einem eigenen DAL. Allerdings liebäugle ich gerade ein wenig mit Gentle.NET. Finde das recht schick und vor allem ist es Open Source.

Aber benutze mal die Forumssuche, zu OR Mappern wurde schon viel geschrieben.

Grüße Sven

S
8.746 Beiträge seit 2005
vor 18 Jahren

In der aktuellen ObjektSpektrum (5/2005) ist übrigens ein toller Artikel von Ralf Westphal, der ziemlich gut beschreibt, warum der Softwareentwurf in "Schichten" nur noch bedingt zeitgemäß ist.

Sein Fazit: Das Wort "Schichten" sollte nur noch im Sinne "Kategorien" (wie eben Geschäftslogik, Präsentation) verwendet werden.

Darüberhinaus sind Schichten sind im Zeitalter der verteilten Systeme kein zweckmäßiges, allgemeines Architekturpattern mehr. Subsysteme nach Schichten aufzubauen kann natürlich nach wie vor Sinn machen.

Rapf ersetzt die "Schichten" durch "Zellen".

Sehr lesenswert.