Archief - [PROG][ASP.NET] Best practices

Obliv` · 21 nov 2006

Hallo,

Ik zit momenteel in mijn laatste jaar Bachelor in de Toegepaste Informatica. Tijdens het tweede semester zal ik de dingen die ik de afgelopen jaren heb geleerd in de praktijk moeten omzetten.

Ik heb gekozen voor een ASP.NET stage bij een bedrijf in Antwerpen. Ik heb deze stage gekozen omdat het onderwerp mij echt boeide.

Maar er is een klein probleem: ik heb maar een zeer kleine cursus ASP.NET gehad (2u/week gedurende 10 weken). Daarom had ik graag van jullie ervaren programmeurs gehoord, aan wat ik zoal moet denken bij de ontwikkeling van een ASP.NET applicatie.

Momenteel werk ik volgens een 3-tier model.
Laag 1: Data Tier
- Hiervoor gebruik ik SQL Server 2005.
- De data in de tabellen wordt alleen benaderd via stored procedures en views. Per tabel is er SP om te updaten, inserten, deleten, selecteren (all), selecteren (id).

Laag 2: Logical Tier
- Deze laag is verder onderverdeeld in de Data Access Layer (DAL) en de Business Logic Layer (BLL).
- DAL: per tabel in de data tier is er in de DAL een klasse die gebruik maakt van de store procedures om data op te halen of te wijzigen. Deze klassen hebben als naam: _[Naam van de tabel].
- BLL: per tabel is er in de BLL een klasse die overerft van zijn klasse in de DAL. In de klassen in de BLL worden eventueel controles geschreven om business logic af te dwingen bij het inserten, updaten of deleten van records. Deze klassen hebben als naam gewoon de naam van de tabel.

Laag 3: Presentation Tier
- Het geen wat de gebruiker te zien krijgt. Paginas met een semantische xhtml structuur. Vormgegeven door CSS.

Voila. Een hele boterham, maar dit is dus mijn methode.

Vraagjes:
- Momenteel maak ik altijd pagina's en laat ik de vb/c# code in dezelfde pagina staan (dus geen .aspx.vb), is dit een slechte methode?
- Is er een mogelijkheid om de rommelcode die een datagrid en dergelijke produceert een beetje te wijzigen (via adapters ofzo)?
- Hoe gaan jullie om met authentication (hier ken ik dus bitter weinig van, eigenlijk alleen maar forms authentication).
- Wat denken jullie van ASP.NET AJAX (formerly knows as Atlas zeker?)
- Kennen jullie goede ASP.NET boeken?
- Hoe gaan jullie om met themes, skins en master pages? Persoonlijk vind ik skins dikke zever ... ik bind liever zelf een css class aan een control.

Als ik nog op vraagjes kom, weet ik jullie wel te vinden

.

Alvast bedankt voor jullie tijd.

Messias. · 21 nov 2006

Obliv` zei:
Vraagjes:
- Momenteel maak ik altijd pagina's en laat ik de vb/c# code in dezelfde pagina staan (dus geen .aspx.vb), is dit een slechte methode?

Bwa slecht. Zeg maar niet netjes. Om het hipjes te zeggen, view en controller gescheiden houden.

Obliv` · 21 nov 2006

Messias. zei:
Bwa slecht. Zeg maar niet netjes. Om het hipjes te zeggen, view en controller gescheiden houden.

Idd, ik ben zelf ook wel een voorstander van dat systeem maar dan heb je wel ongelooflijk veel pagina's soms eh.

Cakeman · 22 nov 2006

Enkele (ASP).NET blogs die ik volg en waarschijnlijk wel handig zijn:
http://weblogs.asp.net/scottgu/default.aspx
http://www.dotnetkicks.com/
http://www.madskristensen.dk/blog/
http://aspalliance.com/

H@voc_!nc. · 22 nov 2006

Obliv` zei:
Idd, ik ben zelf ook wel een voorstander van dat systeem maar dan heb je wel ongelooflijk veel pagina's soms eh.

*g*

Ge maakt in uwe visual studio 3 projecten 1 webproject en 2 classlibraries (1 voor uwe Data tier en 1 voor uwen business logic)

wat ge maakt is per object
ne view, een DataObject Klasse (met uw sqlcommand, transactions etc e.d. in
) En uw businessObject

In visual studio 2005 kunde da webprject gelijk maken in 2003 zou ik ne winforms client maken om te testen en uwe webclient apart developen (omdat da in 2003 a pain in the ass is)

dit is de manier van werken

GEEN programmacode in uw asp paginas
GEEN SQL code in uw programmacode (werk met storeed procedures en commands)

Daar beginde mee (kijk eens naar tools zoals codesmith)

--MUST READ--
http://asp.net/learn/dataaccess/default.aspx?tabid=63

Persoonlijk vind ik skins dikke zever ... ik bind liever zelf een css class aan een control.
--> die skinfiles is de max in .NET 3.0 toch zeker!

UniKorn · 24 nov 2006

H@voc_!nc. zei:
*g*

Ge maakt in uwe visual studio 3 projecten 1 webproject en 2 classlibraries (1 voor uwe Data tier en 1 voor uwen business logic)

FOUT: Best practices and patterns schrijft voor : 1 project per laag.

Hoe wij werken : wij hebben zelf een generieke datalaag geschreven die zowel sql server als oracle ondersteund. Het enige dat die laag mag doen is data doorsturen

Wij hebben een business laag die alle objecten bevat, gebaseerd op het CSLA framework (waar objecten zichzelf valideren etc)
Ieder object heeft properties, maar niet de tabelnaam (omdat sommige mensen hun tabellen tbl_Person noemen)
Ieder object heeft ook tags waarin duidelijk gemaakt wordt wat de tabelnaam en veldnamen zijn

Vb Person met Naam en Voornaam, in tabel tbl_Person (Person_Name, Person_Firstname) hebben we

[tablefield="Person_Name"]
public string Name
{
}

onze datalaag interpreteert dat dan en linkt Name property aan het Person_Name field.dit is de manier van werken

GEEN SQL code in uw programmacode (werk met storeed procedures en commands)

Niet altijd waar. Hangt af wat voor een methodologie ge volgt. Het voordeel van stored procedures is dat ze sneller zijn, en aanpasbaar zonder de applicatie aan te passen. Het nadeel is dat je je business logica in je database steekt.

Obliv` · 24 nov 2006

UniKorn zei:
FOUT: Best practices and patterns schrijft voor : 1 project per laag.

Hoe wij werken : wij hebben zelf een generieke datalaag geschreven die zowel sql server als oracle ondersteund. Het enige dat die laag mag doen is data doorsturen

Wij hebben een business laag die alle objecten bevat, gebaseerd op het CSLA framework (waar objecten zichzelf valideren etc)
Ieder object heeft properties, maar niet de tabelnaam (omdat sommige mensen hun tabellen tbl_Person noemen)
Ieder object heeft ook tags waarin duidelijk gemaakt wordt wat de tabelnaam en veldnamen zijn

Vb Person met Naam en Voornaam, in tabel tbl_Person (Person_Name, Person_Firstname) hebben we

[tablefield="Person_Name"]
public string Name
{
}

onze datalaag interpreteert dat dan en linkt Name property aan het Person_Name field.dit is de manier van werken

Quote:
GEEN SQL code in uw programmacode (werk met storeed procedures en commands)

Niet altijd waar. Hangt af wat voor een methodologie ge volgt. Het voordeel van stored procedures is dat ze sneller zijn, en aanpasbaar zonder de applicatie aan te passen. Het nadeel is dat je je business logica in je database steekt.

Ja, er hangen bij ons wel regels aan de naamgeving van de tabellen en de velden.

Met die stored procedures hoef je toch geen business logic in je DB te stoppen?

En persoonlijk zou ik ook nooit sql in men programma gebruiken. Alleen SP en views.

H@voc_!nc. zei:
Persoonlijk vind ik skins dikke zever ... ik bind liever zelf een css class aan een control.
--> die skinfiles is de max in .NET 3.0 toch zeker!

De reden waarvoor ik niet erg gek ben op skins is omdat ik vind dat opmaak in een CSS file steeks en niet een een asp.net file.

H@voc_!nc. · 25 nov 2006

kan zijn ben nu persoonlijk ook nie zo zot van die skins omdat het wa lang duurt om der ene te maken.

en die 1 project per laag da zeg ik toch da web project is uwen presentation... data laag en business laag da zijn 3 projecten is wel redelijk gesimplificeerd maar soit

Ice · 29 nov 2006

Als ge alles in stored procedures doet, krijgde dan niet ENORM veel stored procedures?

Int begin gade msch wel toekomen met basic create/update/delete/readAll/retrieveById

En dan komen de plezante dingen zoals: ik wille alle orders uit die periode van die klant gesorteerd op adres van klant.
Gade daarvoor ook elke keer een stored procedure schrijven?

Obliv` · 29 nov 2006

Ice zei:
Als ge alles in stored procedures doet, krijgde dan niet ENORM veel stored procedures?

Int begin gade msch wel toekomen met basic create/update/delete/readAll/retrieveById

En dan komen de plezante dingen zoals: ik wille alle orders uit die periode van die klant gesorteerd op adres van klant.
Gade daarvoor ook elke keer een stored procedure schrijven?

Per tabel heb ik momenteel 5 stored procedures (create, retrieveAll, retrieveById, update, delete).

Ik werk momenteel met doodads (code generatie voor DAL, BLL) en die genereerd klassen waarin je de resultaten van de stored procedures kunt wijzigen.

Dus van een overvloed aan SPs heb ik nog geen last gehad.

H@voc_!nc. zei:
--MUST READ--
http://asp.net/learn/dataaccess/default.aspx?tabid=63

Ik heb de eerste artikels al gelezen. Zeer interessant

.

Ik heb nog wat verdere informatie opgezocht over DAL design. De ene raadt aan om het niet via een Typed DataSet te doen, de andere wel...

Wat is nu eigelijk de goede manier?

[DZM]TheOne · 30 nov 2006

ivm datasets
er is geen ideale methode, want beiden hebben hun voor- en nadelen

typed zorgt voor minder programmeerwerk (makkelijkere namen, intellisense in vs.net bvb)

untyped is veel flexibeler, maar vergt vaak meer code

ik zou zeggen google it, en beslis naargelang je noden & ervaring

H@voc_!nc. · 3 dec 2006

indeed das allemaal zo simpel nie Datasets en datatables en zo zijn de gemakkelijkkste oplossingen in samenwerking met databinding en stuff. untyped is af te raken is redelijk gevoelig voor fouten

dJeez · 4 dec 2006

Voor je model kan je uiteraard ook je toevlucht zoeken tot een reeds bestaande ORM oplossing. Voor ASP.Net zou ik NHibernate wel durven aanraden, de .NET port van Hibernate voor Java.

En als je het wiel niet helemaal opnieuw wil uitvinden kan je dan ineens ook opteren voor het gebruiken van een compleet (MVC) framework uiteraard. Spring voor Java of Spring.NET voor .NET is zeker geen slechte keuze.

Moto · 7 dec 2006

De data in de tabellen wordt alleen benaderd via stored procedures en views.

views? bekijkt eens user defined functions, veel leuker

ahja en laat ze niet beginnen met 'sp_' heh

Wat denken jullie van ASP.NET AJAX (formerly knows as Atlas zeker?)

Ajax was formerly known as xmlhttp, ATLAS is crappy shit voor de developers die niet kunnen programmeren, blijf daar gewoon weg van

En dan komen de plezante dingen zoals: ik wille alle orders uit die periode van die klant gesorteerd op adres van klant.
Gade daarvoor ook elke keer een stored procedure schrijven

als het een rapport is tuurlijk, waarom niet?

Per tabel heb ik momenteel 5 stored procedures (create, retrieveAll, retrieveById, update, delete).

Die zijn toch niet gegenereed mag ik hopen

Ik werk momenteel met doodads (code generatie voor DAL, BLL) en die genereerd klassen waarin je de resultaten van de stored procedures kunt wijzigen.

1 gouden regel die ik u al kan geven, code generatie = crap

Obliv` · 8 dec 2006

Moto zei:
1 gouden regel die ik u al kan geven, code generatie = crap

Kan je dat misschien wat argumenteren

?

Bij de meeste code generatoren kan je de template die wordt gebruikt voor code te genereren wijzigen en aanpassen naar je eigen noden.

Handiger bestaat in mijn ogen niet.

Obliv` · 8 dec 2006

Moto zei:
Ajax was formerly known as xmlhttp, ATLAS is crappy shit voor de developers die niet kunnen programmeren, blijf daar gewoon weg van

Ik bedoelde niet echt de gewone ajax, die ken ik al wel goed genoeg. Maar specifiek die ASP.NET Ajax...

Anyway, ik had al wel het gevoel dat ik daar moest van wegblijven

.

UniKorn · 13 dec 2006

Obliv` zei:
Kan je dat misschien wat argumenteren ?

Bij de meeste code generatoren kan je de template die wordt gebruikt voor code te genereren wijzigen en aanpassen naar je eigen noden.

Handiger bestaat in mijn ogen niet.

Yep, kan je dat argumenteren aub? Ik ben volledig akkoord met Obliv hier. Code gen templates kunnen automatisch aangepast worden, zorgen ervoor dat elke programmeur binnen de organisatie van dezelfde basis vertrekt en op een gelijkaardige manier programmeert.

Daarbovenop worden ze getest op verschillende projecten en kunnen ze aangepast worden om een grotere software quality te bereiken.

Als pure schoolse developer sta je daar waarschijnlijk anders tegenover, maar je zal nog wel leren dat codegen de toekomst is.

Om een dom voorbeeld te geven, als je een form maakt in Visual Studio genereert hij ook een groot deel van de code voor het form zelf. Wil je dat ook allemaal zelf gaan schrijven met het risico op fouten?

H@voc_!nc. · 13 dec 2006

As je nu bvb code snippets neemt kwee nie oe een handige tool

code generation is de max... alleen mensen die nog nooit serieuze projecten gemaakt hebben zijn daar tegen...

as ge al een tijdje geprogrammeerd hebt zal je merken dat zeer veel dingen terugkomen... soms is de moeite niet te automatiseren... maar met code snippets in visual studio kan je zeer snel en zeer simpel code blocks maken ik gebruik ze kwee nie hoe veel

anyway puur custom development gaat er in belgië langzaam maar zeker uit

Moto · 13 dec 2006

Mja weet niet welke code generators ge bedoelt maar ik bedoel vooral de "geef-mij-een-db-en-ik-maak-1000-klassen-aan"-generators, compleet anders dan code snippets heh

Daar zit echt wel een hoop bucht bij die door een onervaren programmeur heel makkelijk misbruikt kan worden, wat leidt tot onperformanten brol

Op het werk laats nog een project gezien, maakte gebruik van Atlas en code gegenereed met OR Wilson Mapper, Zo traag en slecht komt ge niet veel tegen

Zou zeker in het begin ze nog proberen niet gebruiken zodat ge weet waarmee ge bezig zijt, en wat stored procedures leert schrijven ed.

Daarna kunt ge altijd iets deftigs leren gebruiken zoals een NHibernate, maar dan nog afwegen wat met NHibernate doen of met stored procedures

Als pure schoolse developer sta je daar waarschijnlijk anders tegenover

schoolse developer? lol

Maar specifiek die ASP.NET Ajax...

Heb laats deze in een project gebruikt en dat werkte toch zeer goed

Archief - [PROG][ASP.NET] Best practices

Obliv`

Legacy Member

Messias.

Legacy Member

Obliv`

Legacy Member

Cakeman

Legacy Member

H@voc_!nc.

Legacy Member

UniKorn

Legacy Member

Obliv`

Legacy Member

H@voc_!nc.

Legacy Member

Ice

Legacy Member

Obliv`

Legacy Member

[DZM]TheOne

Legacy Member

H@voc_!nc.

Legacy Member

dJeez

Legacy Member

Moto

Legacy Member

Obliv`

Legacy Member

Obliv`

Legacy Member

UniKorn

Legacy Member

H@voc_!nc.

Legacy Member

Moto

Legacy Member