Avancerad skandinavisk programmering?

Jag spenderade förra veckan på en .NET kurs i London. Förutom just Webservices som var huvudämnet så pratades det allmänt om .NET-programmering, tillvägagångssätt m.m.

Läraren (och många deltagare) var verkligen superduktig och hade koll på det mesta i .NET inklusive nya ändringar för Whidbey m.m.

MEN...när det då gällde att bygga klasser och vilken arkitektur/struktur man har på sitt kodande så blev jag nerpratad.

Exempel:
Själva jobbar jag nästan alltid med egna Collection-klasser (som ärver av BaseCollection och implementerar IList för att stödja bindning) som fylls på med Property-Klasser. I dessa klasserna styr jag sedan olika beteenden med egna attributklasser och CustomAttributes. Jag använder även XMLAttribute för att kunna styra hur Listor och Data kan Serialiseras. Klienten kan dels:
- Binda data mot div. kontroller
- Ändra data i en Property-Klass och skicka tillbaka den till BL, som då med automatik uppdaterar data baserat på CustomAttributes.
- m.m m.m.

Det känns för mig som ett väldigt bra sätt, då man har full dynamik och flexibilitet på sitt data.

De däremot hävdade att man i princip alltid ska använda ett Dataset för att returnera data från BL. Sen kan klienten fixa till det som den vill, posta tillbaka ändringar m.m.

Läraren sa iof inte att mitt sätt är fel, men däremot för "avancerat". Då han själv haft kontakter i skandinavien innan sa han bla:

"Ni skandinaver ägnar massa tid åt att bygga avancerade klasser och kontroller, när det mesta redan finns klart i .NET, varför? För mina kunder är min tid pengar, och det är snabbare att använda ett Dataset..."

Visst kan det ta lite mera tid att ägna några tankar åt bra struktur, men har man väl gjort det en gång, så har man en bra uppsättninge med basklasser för återanvändning.

Så...kommentarer på det? Nån som har erfarenhet av hur man bygger i andra länder? Hur gör Ni?

Jag håller annars helt klart med om att tex. ett Dataset kan vara det bästa i vissa situationer. MS har ju ändå lagt en helt del resurser på att få det bra, särskilt gällande relationer, mapping m.m...Men återigen föredrar jag mina egna klasser....

Intressant!
Nu gör ju jag långt ifrån lika avancerade saker som en del här verkar göra, men hur som helst - här kommer lite info om min kodning. :)

Jag använder sällan inbyggda tekniker fullt ut, att exempelvis använda ett dataset för en massa ändamål känns inte vettigt om man kan hitta en annan metod som ger bättre prestanda. Jag lägger gärna ner mer tid på att prestandan ska bli bättre, än att applikationen ska skrivas ihop snabbt och fungera.
Det kan bli ganska avancerat i vissa fall, men när man väl fått till det sitter man på en bra lösning, som förmodligen är bättre än den som är snabbast ihopskriven.

Även sådana triviala saker som enkla admingränssnitt för att lägga till, redigera/uppdatera och radera info i databaser skriver jag själv - även om det numera finns "enklare" sätt att tillgå. Det är tråkigt - men är mer prestandavänligt. Å andra sidan kan man ju fundera över nyttan med prestandavänlighet om admingränssnittet används nån gång i månaden, men det är en annan femma.

I alla fall - jag skriver ihop mina egna lösningar, i stället för att använda befintliga. Den dagen kommer kanske då man prioriterar prestanda framför kort utvecklingstid, och då har man fördelar.

Jag är faktiskt raka motsatsen till m_soderlund måste jag säga.
Kanske beror det på lathet eller att jag helt enkelt finner det flesta funktioner jag behöver redan inbyggda i .net. Varför uppfinna hjulet två gånger?

Dessutom har de inbyggda funktionerna ofta benägenheten att vara väldigt optimerade för en hel del.
Vad man då skulle kunna vinna genom att bygga en egen är att man sen har en specialfunktion som är snäppet snabbare på just en enda operation, istället för en funktion som är _nästan_ lika snabb på samma operation samt på en hel del liknanden operationer.

Och även om man skulle bygga egna lösningar för ett visst problem har jag fått för mig att de inbyggda lösningarna ofta ändå kommer visa bättre prestation i de flesta fall. De är ju ändå gjorda för att användas mycket och borde redan vara testade tillräckligt för att kunna kallas godkända ut prestandasynpunkt.

Men det handlar ju om hur lösningarna ska användas först och främst.
Jag lägger inte ner 10 timmar extra på att bygga en funktion som det skulle ta 30 minuter att implementera en befintlig klass/namnrymd, med kanske eventuellt inte _riktigt_ det utseendet jag ville ha från början.

Varför uppfinna hjulet två gånger?

Grejen är väl att om man väl har byggt en riktigt bra basklass, med stöd för div. attribut m.m. så kan den ju implementeras i alla nya projekt, och då har man i längden inte förlorat mer tid än det tog att bygga den första gången.

Sen gällande prestanda, så bygger ju de flesta .NET-objekt på andra .NET-objekt. Tex. ett Dataset/Datatable genereras ju internet i DataAdaptern med en Reader. Och då kan jag ju också använda en Reader för att göra samma sak.
När sen "Generics" kommer i Whidbey, så kommer typsäkerheten öka både prestanda och struktur ännu mer.

Sen handlar det inte bara om prestande, utan även mycket om användarvänlighet och dynamik.

Låt oss säga att jag binder en Repeater mot ett Datatable. I ItemDataBound placerar jag sedan ut data från kolumnerna i div. kontroller. Syntaxen jag då måste använda (om jag inte använder TypedDataSet) är ju .Item("MY_COLUMN").
Dels så måste jag ju här veta det exakta namnet på alla kolumner och så måste jag explicit typkonvertera för att skriva ut tex. datum i en datumkontroll.

Om jag däremot har mina egna listor och Property-Klasser, så kan jag i ItemDataBound helt enkelt konvertera "E.Item.DataItem" till min egen Property-klass och sedan använda "Intellisens" för att hämta namnet på mina egenskaper, rätt datatyp får jag dessutom på köpet.

Men...jag säger absolut inte att det ena eller andra är rätt eller fel...alla sätt är ju bra utom dem dåliga..! :)

fredrik skrev:

Varför uppfinna hjulet två gånger?

Grejen är väl att om man väl har byggt en riktigt bra basklass, med stöd för div. attribut m.m. så kan den ju implementeras i alla nya projekt, och då har man i längden inte förlorat mer tid än det tog att bygga den första gången.

I sådana fall har man egentligen inte uppfinnit hjulet två gånger, utan snarare uppfunnit svävaren utifrån hjulet. ;)
Om man bygger en lösning med en massa speciella attribut är det kanske inte en allt för onödig lösning.
Det jag menade var att man istället för t.ex. dataset bygger en datasetModified med många färre funktioner än dataset men med en knapp prestandaskillnad.

Japp, det ligger nåt i det! :)

Men alltså...det här fick mig att tänka till...tänker jag för mycket på att alltid leverera 100% bra kod när det i vissa fall hade räckt att leverera en lösning som helt enkelt fungerade?

I en MS-reklam om .NET och ett seminarie de hade för nåt år sen stod det något i stil med:

"Det finns program som helt enkelt gör sitt jobb. Men så finns det de program där dessutom varje kodrad är så snyggt skriven att det ser ut som en hantverkare har gjort det"

Ja, visst är det "klyschigt" och flummigt...men själv känner jag att jag vill kunna leverera riktigt bra kod. Att tänka sig att man skriver en bok när man kodar brukar vara bra...

Jag håller verkligen med dig, fredrik! Man behöver inte alltid vara bunden till de lättaste metoderna för att fixa saker och ting - man utvecklar själv! Dessutom tror jag att man lär sig betydligt mer själv genom att skriva egen kod i stället för att använda sig av MS:s inbyggda tekniker pga att man är lite lat.

Med det är det inte sagt att de som använder MS:s inbyggda tekniker är lata. I vissa fall (som cyprys skriver) är prestandavinsten försumbar (eller inom felmarginalen) och då är det ingen idé att utveckla något helt eget. :)

Men alltså...det här fick mig att tänka till...tänker jag för mycket på att alltid leverera 100% bra kod när det i vissa fall hade räckt att leverera en lösning som helt enkelt fungerade?

Jag som inte är en programmerare har många gånger tänkt just i dessa banor när det gäller våra egna applikationer... jag tror att vi (dom ;) ) många gånger har lagt för mycket tid på avancerad kod, skalbarhet, funktionalitet osv än vad som kanske egentligen är bra. Upplever att det är för mycket teknik och för lite människa... kunder är ofta människor som bekant. Det är väl här som jag ofta krockar med datalogerna (och jag vinner sällan).

Vi har arbetat en hel del på olika produkter nu och om ni frågar mig så känns det som att vi skulle kunna ha gjort samma sak på en bråkdel av tiden om vi hade gjort det enkelt för oss, nämligen gått tillbaka till gammalt hederligt hemsidesnickrande. Vad vi har idag är produkter som visserligen är bra (tycker vi såklart! :) ) men nyttan av det vi gjort är nog svår att se innan vi har 50000 kunder och det kommer inte att inträffa.

Tekniken springer om sig själv på något sätt när tekniken finns för sin egen skull. För användaren handlar det egentligen om två saker - presentationslagret och tiden.

Fredrik, sa han samma sak ang Databasklasser som de flesta härinne bygger?

Jag använder i princip aldrig DataSet, bygger alltid egna affärslagerklasser för att just få en vettig och snygg struktur. Detta för att både kunna bygga ut det lättare, koda vidare lättare och få en vettig struktur på vad saker gör för något. Ett DataSet, som jag känner det, har inte denna klara struktur och innehåller dessutom ett antal funktion som ej är relevanta i vissa sammanhang, därför föredrar jag att skriva egna Collections och klasser.

"Ni skandinaver ägnar massa tid åt att bygga avancerade klasser och kontroller, när det mesta redan finns klart i .NET, varför? För mina kunder är min tid pengar, och det är snabbare att använda ett Dataset..."

För mig är det inte snabbare att använda ett Dataset än att använda mig av egna objekt och collections. Din lärare har nog inte hört talas om återanvändbar kod. Jag generera min kod utifrån databasen och får då ett färdigt lager med klasser och collections som är klara att användas.

Sedan är det så att det finns markanta prestandaskillnader i att använda sig av DataSet och egna collections. Det märks inte på små applikationer men märks när man får många användare. En annan sak är att DataSets är riktigt usla i prestanan jämf med collections vid Remoting, det tar bra mycket längre tid att skicka ett DataSet än en collections med egan klasser över nätet.

Du kan heller aldrig få ett helt OO synsätt om du använder dig av DataSets istället för klasser och collections, samt att många av de Patterns som finns blir jobbiga om man skall implementera dessa med DataSets, framför allt blir det massor med overhead.

Allt detta har nu MS insett och kommit på att DataSets inte är guds gåva till programmeraren, och därför implementerar man en OR/Mapper i Whidbey. Det kanske du skall påpeka för din lärare.

- Magnus

Nöff skrev:

Fredrik, sa han samma sak ang Databasklasser som de flesta härinne bygger?

Njae, inte riktigt :)
Gällande databasklasser (DAL) så var dialogen:

- "Hur många av Er bygger egna DataKlasser?"
Ca 75% av händerna sträcktes upp.

- "Hur många av Er gör något ANNAT i dessa klasser än att just wrappa in ADO.NET-teknik?"
Inte lika många händer.

- "Varför göra något som redan finns? Jag köper om ni bygger in logik som gör något annorlunda än de vanliga ADO-klasserna. Men 90% av de DAL-klasser jag ser, gör inget annat än att just wrappa in ADO"

Gladh skrev:

Din lärare har nog inte hört talas om återanvändbar kod.

Jo, det tror jag faktiskt. Han var vädigt duktig i både .NET och "allmän" programmering, såsom OO-metodik, UML osv.
För visst kan man använda återanvändbarkod med Datasets. Du kan ju fortfarande bygga BL-klasser som är återanvändbara, fast med Datasets.
Ett TypedDataset har ju dessutom all logik för både typsäkerhet, "grundvärde" och inte minst relationer. Men visst är det aningen slöare.

Jag håller helt och hållet med dig. Jag gör också på samma sätt med egna collectionklasser, automatgererad och dynamisk kod m.m. Men poängen här var att jag i princip blev HELT nerröstad i mitt sätt att inte använda Datasets, och inte bara av läraren utan av de andra utvecklarna med. Och många av dem var verkligen duktiga, utvecklare på bla. AskJeeves, HondaMotors m.m.

Gladh skrev:

En annan sak är att DataSets är riktigt usla i prestanan jämf med collections vid Remoting

Ja, det låter rimligt. Men Remoting verkar ju enligt MS ändå inte vara sättet man i framtiden kommer att använda. I och med Indigo kommer det garanterat nya och bättre sätt och kommunicera binärt via TCP tex. Remoting via TCP känns som ett ganska svårhanterligt sätt att sätta upp kommunikationen på idag iaf (tycker jag).

Gladh skrev:

Det kanske du skall påpeka för din lärare.

He he...ja, jag får väl skicka ett mail och referera till wF... :)

Gladh skrev:

implementerar man en OR/Mapper i Whidbey

Hmm...måste ha missat det...hur ska den funka/mer läsning?

Gladh skrev:

Ett DataSet, som jag känner det, har inte denna klara struktur och innehåller dessutom ett antal funktion som ej är relevanta i vissa sammanhang

Jo, fast om du använder ett TypedDataset så får du ju alla kolumner som Properties och de extra funktionerna som finns är ju bara Null-pekare tills dess att man använder dem.

Ja, själv håller jag fast vid mina collectionsklasser, och iom Generics i .NET 2 så får man ytterligare en anledning att fortsätta med det.

Tack för alla inputs!

Jo, det tror jag faktiskt. Han var vädigt duktig i både .NET och "allmän" programmering, såsom OO-metodik, UML osv.

Han är säkert jätteduktig, det är bara att jag menar att det tar inte längre tid att generera ett BL med en O/R Mapper om man genererar koden automatiskt utifrån databasen, eller tvärtom, genererar databasen efter BL. Så att säga att man får någon tidsvinst att använda DataSet istället är lögn.

Sedan så gör jag inga speciella Data/Bussines klasser utan bygger in BussinesLogik i mina klasser så de har både Data och logik, vet att det diskuteras att man skall dela upp det i Dataklasser och Logikklasser (alltså men massa Manager-klasser som opererar på dataklasserna). Jag tycker dock om att sammla så mycket relevant kod i samma klass.

Exempel är om jag gör en webshop, då har jag en Order klass/collection och en OrderItem klass/Collection. OM jag då lägger logik i min Order klass på funktionen spara, så betyder det att den spara ner både min Order klass och alla de OrderItem som tillhör denna klass, och fixat till referenserna i databasen.

Remoting via TCP känns som ett ganska svårhanterligt sätt att sätta upp kommunikationen på idag iaf (tycker jag).

5 rader kod på servern, och 3 rader kod på klienten sedan har du en koppling där emellan och kan skicka object. Det är inte specillet svårt, tar liten stund innan man fattat riktigt vad som händer, men sedan är det glassklart.

Hmm...måste ha missat det...hur ska den funka/mer läsning?

Finns massor med info på nätet. Här är dock MS syn på OS.NET http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dnadonet/html/objectspaces.asp

- Magnus

Kanon! Tackar för det, får ta och läsa på lite! :)

Med Remoting så har jag bara provat att köra SOAP-HTTP "style", och fick inte igång TCP-sättet ordentligt.

Nej, du har rätt i att det klart går snabbare om man använder autmatgenererad kod att koda. Jag håller med.

Jaja, hur som helst så är det alltid intressant att se hur andra gör!

Lite OT, men vilket verktyg använder ni för att generera kod från era modeller? Vad jag förstår så klarar inte Rational rose(som jag använt mest) av att generera kod i C#.

Hmm, men gör inte dagens VS.NET detta?. Såsom klicka på Server explorer, dra in en tabell, så skapas en dataadapter med alla SELECT,INSERT,UPDATE för just den tabellen, och sen högerklicka på adaptern "Generate DataSet" så har man ju fått en liten OR/mapper? :). dock inte för relationer och sånt, eller är det nåt annat ni talar om?.

"Generate DataSet" så har man ju fått en liten OR/mapper?

Dataset och O/R Mapper har inte ihop i samma mening. Så jag skulle inte vilja säga att du har en O/R mapper inte ens en liten en.

- Magnus

Men är det inte det som är O/R mapper att databaskolumnerna blir ett objekt's egenskaper istället?.

sqlDataAdapter1.Fill(dataSet11); //fyll dataset:et med data från databasen.

dataSet11.kunder[0].produkt="brädor"; //ändra dataset

sqlDataAdapter1.Update(dataSet11); //skicka in dataset:et i adaptern så uppdateras databasen med det ändrade värdet.

Eller om jag vill lägga till en rad i databasen.

dataSet11.kunder.AddproduktRow("grytlappar");
sqlDataAdapter1.Update(dataSet11);

och jag har inte skrivit en rad SQL :D

Men är det inte det som är O/R mapper att databaskolumnerna blir ett objekt's egenskaper istället?.

Ju det stämmer, men ur ett O/R mapper perspektiv så blir varje tabell sin egen klass, och varje rad ett object. Alltså får du en Object Orienterad struktur när du flyttar data från din databas till din applikation, det får du inte med ett dataset.

- Magnus

Så med andra ord är SQL språket på väg att dö ut?.
Eller åtminstone kommer det abstraheras bort från programmerarna?.