ASP.NET Einsteigerfrage [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : ASP.NET Einsteigerfrage

Gast

2006-03-16, 07:44:10

grakaman

2006-03-16, 08:22:49

Hallo,

ich habe bisher nur PHP gemacht und möchte nun ein grösseres Projekt mit ASP.NET erstellen.

Deshalb habe ich ein paar grundlegende Fragen zum Seitenaufbau: Wenn ich ein Menü habe, kann ich dass dann ähnlich wie in PHP 'includen' oder bin ich gezwungen, Frames zu verwenden?

Ich kann hier nur von ASP.NET 1.x reden, weil ich das ganze 2.0er Framework mir noch nicht so angeschaut habe. Prinzipiell macht man bei ASP.NET aber nichts mit inkludes im herkömmlichen Sinn, obwohl das Server Tag für das Inkluden von Dateien weiterhin unterstützt wird. Die Vorgehensweise ist hier eher so, dass du z.B. ein User Control (.ascx Dateien) hast und dessen Klasse zur Controls Collection der Page Klasse (.aspx Dateien) hinzufügst.

Kann man den Aufbau eines ASP.NET-Projekts überhaupt mit dem eines PHP-Projekts vergleichen, also was die Seitenstruktur betrifft?

Weniger, eigentlich gibt es hier gravierende Unterschiede. Klar hast du hier auch Seiten, aber du solltest das zu Grunde liegende Objektmodell bzw. dessen Funktionsweise erst einmal verstehen.

Oder kann ich davon ausgehen, dass Seiten m. ASP.NET mit PHP gar nichts zu tun hat, dann fang ich nämlich gleich noch mal von vorne an was solche Überlegungen betrifft.

Vereinfacht könnte man das schon gleichsetzen, wobei es aber eben in der Funktionsweise gravierende Unterschiede gibt.

Hier mal ein paar Links:

Tutorial für ASP.NET 1.0: http://www.dotnetjunkies.com/quickstart/aspplus/doc/quickstart.aspx

Turoial für ASP.NET 2.0:
http://www.asp.net/QuickStart/aspnet/Default.aspx

dt. Seite zu ASP.NET:
http://www.aspheute.com

Seite mit unheimlich vielen Tutorials/Codebsp.:
http://aspalliance.com/

Gast

2006-03-16, 13:36:17

Danke für die Antwort!
Die Vorgehensweise ist hier eher so, dass du z.B. ein User Control (.ascx Dateien) hast und dessen Klasse zur Controls Collection der Page Klasse (.aspx Dateien) hinzufügst.Hab mich ein wenig eingelesen. Das mit den Controls erinnert mich an Tags in JSP. Wie kann ich mir das aber konkret Vorstellen? Könnte dann meine index etwa so aussehen?

<%@ Register Tagprefix="mycontrol" Tagname="..." src="mycontrol.ascx" %>
<mycontorl:header runat="server" />
<mycontorl:menulinks runat="server" />
<mycontorl:content runat="server" />
<mycontorl:footer runat="server" />

Oder ist das übertrieben, werden Controls eher zur Darstellung von einzelnen Steuerelementen verwendet? Strukturieren liesse sich die Seite damit ja schon. Den Code hinterleg ich dann nach wie vor in der .aspx.vb Datei, die zu der Seite gehört.

Der Aufbau meines Projekts sieht ganz grob mal so aus:
webseitenbereich (1 aspx-Datei ?)
adminbereich (1-2 aspx-Dateien ?)

oder ist es sinnvoller hier mehrere aspx-Dateien anzulegen? Wenn ich mehrere Dateien hätte und nur 1 Code-Datei, dann hätte ich dann auf die Variablen einer aspx-Datei nur noch beschränkt Zugriff, auf alle Fälle müsste man vorsichtiger mit den Variablen umgehen, da nicht bekannt ist welche gerade verfügbar sind.

Die Seiten sollten möglichst flexibel bleiben, eine Art Drei-Schichten-Modell wird zum Einsatz kommen.

grakaman

2006-03-16, 14:19:32

Danke für die Antwort!
Hab mich ein wenig eingelesen. Das mit den Controls erinnert mich an Tags in JSP. Wie kann ich mir das aber konkret Vorstellen? Könnte dann meine index etwa so aussehen?

<%@ Register Tagprefix="mycontrol" Tagname="..." src="mycontrol.ascx" %>
<mycontorl:header runat="server" />
<mycontorl:menulinks runat="server" />
<mycontorl:content runat="server" />
<mycontorl:footer runat="server" />

Wenn du das ganze deklarativ machst, dann ja. Im obigen Fall müsstest du dann aber für jedes Control eine Register Direktive hinzufügen. Du kannst das ganze aber auch aus der Codebehind Datei dynamisch einladen. Ich habe lange nichts mehr mit ASP.NET gemacht, also keine Garantie für Korrektheit:

// in der System.Web.UI.Page Klasse
UserControl myControl = LoadControl("MyUserControl.ascx");

Der Nachteil hier wäre, dass du nicht genau weißt, wo das Control in die Seite eingeladen wird, deswegen am besten noch mal einen Platzhalter auf der Page deklarieren. Hier kommen auch die Html/Web Controls ins Spiel. Für alle Html Controls gibt es eine serverseitige Implementierung. Du könntest das dann z.B. so machen. Auf der ASPX Page deklarierst du z.B.:

<table....>
...
<td id="myPlaceHolder" runat="Server" />
</table>

In der Codebehind definierst du dann erst mal das TableCell Control und fügst das UserControl dort hinzu.

System.Web.UI.HtmlControls.HtmlTableCell myPlaceHolder;
....
UserControl myControl = LoadControl("MyUserControl.ascx");
myPlaceHolder.Controls.Add(myControl);

Oder ist das übertrieben, werden Controls eher zur Darstellung von einzelnen Steuerelementen verwendet?

Dazu musst du unterscheiden. ASPX Dateien entsprechen sozusagen einer Html Seite, ASCX Dateien sind quasi Include Dateien und können nur innerhalb von ASPX Seiten verwendet werden. Der Dreh- und Angelpunkt sind dann nun aber die HtmlControls/WebControls. HtmlControls stellen quasi einfache Html Elemente dar und erweitern die um ein einfaches serverseitiges Objektmodell. WebControls sind quasi die Luxusausführung und beinhalten von einfachen normalen Html Elementen bis hin zu komplexen zusammengetzten Elementen (z.B. ein Kalender) die ganze Palette. Freilich kannst du auch deine eigenen custom Controls schreiben und rendern. Du kannst auch zusammengesetzte Controls schreiben, also bestehende Controls kombinieren und um eigene Logik erweitern. Die Möglichkeiten sind einfach enorm, du musst dich da schon selbst schlau machen :)

Wenn ich mehrere Dateien hätte und nur 1 Code-Datei, dann hätte ich dann auf die Variablen einer aspx-Datei nur noch beschränkt Zugriff, auf alle Fälle müsste man vorsichtiger mit den Variablen umgehen, da nicht bekannt ist welche gerade verfügbar sind.

Verstehe ich nicht ganz, was du meinst. Du hast für jede ASPX Datei eine dazugehörige Codebehind Datei. Die jeweilige Klasse in der Codebehind Datei ist von Page abgeleitet und die ASPX Seite refreenziert dann diese Klasse. Um flexibel zu sein wäre es aber ratsam eine Basisklasse zu schreiben (die von Page erbt) und jede Codebehind Klasse erbt dann von dieser Basisklasse.

Kabelsalat

2006-03-16, 14:20:13

Für obiges solltest du (sofern .Net2 zum Einsatz kommt) Masterpages verwenden.

grakaman

2006-03-16, 14:33:37

Für obiges solltest du (sofern .Net2 zum Einsatz kommt) Masterpages verwenden.

Genau, du kannst sie dir aber auch unter ASP.NET 1.x selbst bauen. Das habe ich schnell gefunden: http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=952fe046-3a4d-456a-b0f8-58e7a4df0881

Ich hatte mir aber damals den Code von wilsondotnet.com angesehen. Aber bei der ASP.NET 2.0 Version sollte der Designer Support im VS.NET wesentlich besser sein.

Gast

2006-03-16, 16:32:02

ja es kommt .net2 zum einsatz, habe aber das meiste bisher nur mit .net1 gemacht, mit asp.net eigentlich noch fast gar nichts, es scheint aber viele unterschiede zu geben. ich schau mir das mal an. masterpage.. klingt interessant.

ja man kann mit .net2 10x mal mehr machen als mit .net1, was etwas zu meiner verwirrung beiträgt..

Kabelsalat

2006-03-16, 19:04:47

grakaman

2006-03-16, 19:53:15

Du kannst mit .Net2 genau das selbe machen wie mit .Net1, bloß teilweise erheblich einfacher - sprich in .Net 1 hättest du viele Funktionen selber entwerfen müssen, wohingegen .Net 2 vergleichbare bzw. sogar bessere Lösungen von Haus aus mitbringt...

Vermute ich auch. Es gibt aber einen guten Grund für 2.0 und zwar partielle Klassen. Darüber hinaus braucht man bei ASP.NET 2.0 in der Codebehind Klasse keine Deklaration für die Control Klassen, um auf die Controls zuzugreifen. Das konnte bei ASP.NET 1.x schon mitunter sehr unübersichtlich werden (außer man verwendet vielleicht #region/#endregion in VS.NET). Allerdings haben sie das bei ASP.NET anders als bei Windows Forms 2.0 gemacht. Dort wird ja alles vom Designer in ein anderes File geschrieben, dank partiellen Klassen). Bei ASP.NET 2.0 habe ich allerdings noch keins gesehen, deswegen muss das dort anders funktionieren. Was noch erwähnenswert ist, bei ASP.NET 2.0 müsste man, wenn man will, gar keine ASPX/ASCX Dateien mehr unbedingt auf den Web Server schieben, sondern kann einfach die Assembly verwenden.
Bei ASP.NET 1.x war es noch so, dass man ja lediglich die Codebehind Dateien kompilierte. Zur Laufzeit musste da die ASP.NET Runtime dann einmalig noch die ASPX/ASCX Dateien parsen und die endgültigen Klassen erstellen, die dann von der Codebehind abgeleitet war und ggf. die Control Klassen aus den ASPX/ASCX Files, die dort nur deklarativ standen, instanzieren. Und das ganze natürlich dann noch kompilieren und anschließend jitten. Das war zwar trotzdem schon sehr performant, weil es ja nur einmalig für eine Website stattfand (außer jemand hat was an den Files geändert und den Hash somit geändert, in dem Fall hätte die Engine noch mal alles wieder neu geparst/kompiliert), aber mit 2.0 hat man es eben noch weiter optimiert. Das fällt ja jetzt alles weg, weil zur Laufzeit nur noch gejittet werden muss. Aber das nur so am Rande erwähnt :-)

Kabelsalat

2006-03-16, 21:42:28

Bei den Windows-Forms wird der komplette "Designer"-Code in eine separate partial-Class geschrieben. In dieser Klasse findet programmatisch die komplette Beschreibung der Oberfläche statt. Bei ASP.Net sieht das ganze etwas anders aus und man muss zwischen verschiedenen Modellen unterscheiden:

[Im Folgenden ist die Bezeichung ASPX equivalent zu ASCX]
Single-File-Modell: Sowohl Code, als auch Markup befinden sich in der ASPX-Datei. Hierbei braucht sich der Entwickler nicht um das deklarieren der Control-Variablen kümmern.

Codebehind-Modell (VS2002/3): Die ASPX-Datei wird intern als Klasse aufgefasst, welche von der im Codebehind enthaltenen Klasse ableitet. Dabei enthält die ASPX-Datei i.d.R. Markup und die Codebehind-Datei Code bzw. genauer eine Klasse welche von einer entsprechenden Basisklasse ableitet. Dort müssen Controls explizit deklariert werden.

Codefile-Modell (VS2005/.Net2): Wie bei dem ASP.Net1-Modell enthält die ASPX-Datei i.d.R. Markup und die Codebehind-Datei Code. Die von der ASPX-Datei repräsentierte (bzw. daraus generierte) Klasse leitet weiterhin von der im Codebehind enthaltenen Klasse, ab, diese ist aber nun als partial zu kennzeichnen und Controls müssen nicht mehr explizit deklariert werden (dies darf sogar nicht geschehen, weil es sonst zu Namenskonflikten kommt). Als partial muss die Klasse gekennzeichnet werden, da ein entsprechendes Gegenstück mit den Deklarationen der Controls (usw.) automatisch generiert wird [1].

Web-Application-Project (VS2005/.Net2): Sehr ähnlich zu dem Windows-Forms-Modell (und dem VS2003-Codebehind-Modell). Das Markup befindet sich in der ASPX-Datei, Code in dem Codebehindfile und die Deklarationen der Controls und einige weitere Dinge befinden sich in einer separaten partial-Class.

Bei den einzelnen Modellen habe ich vorangig Bezug auf VS- und nicht die .Net-Versionen genommen, da man mit .Net2 sehr wohl noch das alte Modell verwenden kann, aber die Unterstützung seitens des neuen Visual Studio fehlt. Etwas ähnliches wie das aus den VS-Vorgängerversionen bekannte Webprojekt wird es aber schon bald auch für VS2005 geben: Das Web Application Project (http://webproject.scottgu.com/) (http://webproject.scottgu.com/%29).

PS: Bei der Schilderung der drei Modelle bin ich sehr oberflächlich vorgegangen und einige Punkte sind bei genauerer Betrachtung nicht 100% korrekt, erleichtern aber die knappe Schilderung.

PS2: In Hinblick der .Net2-Precompilation-Features könnte das Web-Deployment-Project für den ein oder anderen interessant sein: http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspx

[1] (http://msdn.microsoft.com/asp.net/reference/infrastructure/default.aspx?pull=/library/en-us/dnvs05/html/sitemaint.asp#sitemaint_topic3)
SP.NET 2.0 offers four different compilation models for a Web application:

Normal (ASP.NET 1.x). In a normal ASP.NET Web application, the code-behind files were compiled into an assembly and stored in the /bin directory. The Web pages (ASPX) were compiled on demand. This model worked well for most Web sites. However, the compilation process made the first request of any ASP.NET page slower than subsequent requests. ASP.NET 2.0 continues to support this model of compilation.
Batch compilation. In ASP.NET 2.0, you can batch compile any application with a single URL request. As with ASP.NET 1.x, batch compiling removes the delay on the first page request, but creates a longer cycle time on startup. In addition, batch compilation still requires that the code-behind files are compiled pre-deployment.
Deployment pre-compilation. A new feature of ASP.NET 2.0 allows for full compilation of your project prior to deployment. In the full compilation, all of the code-behind files, ASPX pages, HTML, graphics resources, and other back-end code are compiled into one or more executable assemblies, depending on the size of the application and the compilation settings. The assemblies contain the entire Web site (except Web.config). This compilation method provides for the greatest performance and security at the cost of removing all ability to modify the Web site post deployment. If you are working with highly visible or highly secure Web sites, this option is the best choice for final deployment. However, if you are building a small site running on your local intranet, and the site changes frequently, full pre-compilation may be overkill.
Full run-time compilation. At the other extreme of deployment pre-compilation, ASP.NET 2.0 provides a new mechanism to compile the entire application at run time. That is, you can put your un-compiled code-behind files and any other associated code in the new \code directory and let ASP.NET 2.0 create and maintain references to the assembly that will be generated from these files at run time. This option provides the greatest flexibility in terms of changing Web site content at the cost of storing un-compiled code on the server.
Choosing the best compilation option will depend on your exact circumstances and needs. However, the compilation model remains flexible. Even if you choose to make use of the \code directory to store your code-behind files, you may still deploy your application using the full compilation method.

For more details on the compilation models, see ASP.NET 2.0 Internals (http://msdn.microsoft.com/asp.net/reference/infrastructure/default.aspx?pull=/library/en-us/dnvs05/html/internals.asp).

Gast

2006-03-16, 23:03:58

Wollte noch auf die Tutorial-Videos hinweisen, die es ms anbietet: http://msdn.microsoft.com/asp.net/learning/learn/newtodevelopment/default.aspx
Dort wird unter anderem auch die Verwendung von Masterpages erklärt.

Gast

2006-03-17, 00:55:24