61 svar · 2 845 visningar · startad av rhdf · sida 3 av 4
Jag tänkte sätta mig och börja sanera upp i koden på ett av mina små "hobbyprojekt", en webbshop. I dagsläget så kör ett par sidor olika versioner av den, men jag tänkte nu sätta mig och äntligen bygga "kärnan" i systemet så generiskt som möjligt. Nåväl Om man tar en så pass enkel(?) sak som en produkt. idag har jag en funktion, GetProductByID i klassen ProductsBLL, den Returnerar ett objekt av t
Läs frågan i sin helhet →
Assemblynamn:
namespaces
[Projekt].DomainLayer.dll
[Projekt].Customer
[Projekt].Order
[Projekt].Repositories.ICustomerRepository
[Projekt].Repositories.CustomerRepsoitory
[Projekt].WebClient.dll
Lite roliga saker här.
[Projekt].Repositories.dll (om man nu bryter ut sina repositories.)
[Projekt].Repositories.CustomerRepository
På detta sättet kommer Order och Customer automatiskt vara känt i WebClient och Repisitory namespacen :),
Nja... Layer låter för åldrigt :-) DNA ftw... NOT!!!
Mina heter...
<Company>.<Product>.<layerName>.<moduleName>
layerName = Domian, Application, Infrastructure etc... utan suffixet Layer...
Men det är väl som med allt annat smaksak... Men tycker inte man behöver säga Layer då man redan har spcifika namn för sina delar.
Agree. Att döpa något till layer är som att döpa en metod till CalculateSalaryMethod() ;)
erka skrev:
Agree. Att döpa något till layer är som att döpa en metod till CalculateSalaryMethod() ;)
Men så döper jag alla mina metoder!! :bla :birp
erka skrev:
Agree. Att döpa något till layer är som att döpa en metod till CalculateSalaryMethod() ;)
Hehe.. :bire
För att använda rätt likhet till Method, så skulle det vara Assembly, typ:
WinGraphAssembly.dll..
Jag använder Layer eftersom Evans pratar om DomainLayer, ApplicationLayer etc.. så tycker jag det är bra namn för att tydligöra vad som finns i mina assemblies.. Uncle Bob beskriver tydligt detta i sin bok "Clean Code":
"Go ahead and use computer sience terms, algorithm names, pattern names, math terms, and so forth. Choosing technical names is usually the most appropriate course".
Han tar upp ett exempel "AccountVisitor" där han säger att det är helt ok att lägga till Visitor för att tydligöra föra andra utvecklare att det är Visitor pattern som används.
Ett tydligt namn på Assembly är grymt viktigt! Det gäller att förstå vad som finns i en assembly..
Namn som Domain, Application, Infrastructure, är namn som Uncle Bob skulle kalla "dåliga namn" enligt hans bok, för dom kan ha så olika betydelser, tex Domain kan ha flera betydelse för en utvecklare, Application är ett dåligt namn för Application är ett program.. därför anser jag att ApplicationLayer är betydlig bätter och beskrivande. För Application som namn har en helt annan betydelse än vad ApplicationLayer har. Det är stor skillnad på vad en Application är och vad ett ApplicationLayer är. Layer är en term som används blad arkitekter och system designer i alla år och även nu och kommer alltid att användas.. Sedan vet iofs många utvecklare att DDD har används i projektet, så dom skulle ev förstå Application..
Att använda de namn som Eric använder i sin bok (Alla utvecklare som använder DDD vet vad DomainLayer är och ApplicationLayer etc, men de vet inte vad man syftar på om man skriver tex Application, om inte en tydligt guidlines är framtagen.. men jag tycker inte Application är ett bra namn att ha med i en guidlines, för skulle jag se en assembly med namnet Application, så skulle jag tro implementation av klienten ligger där).
Iof. när det gäller rena GOF-mönster så händer det att jag implementerar dem med beskrivande klassnamn, för det snabbt ska ses vad klassen gör. Men att döpa en assembly med Layer stör jag mig på, tycker inte om det helt enkelt. Har en del större applikationer som är skapade för några år sedan då jag och övriga på avdelningen hade blivit nyfrälsta av Evans, frälsningen finns i stora delar kvar dock inte Layer som suffix :)
erka skrev:
Iof. när det gäller rena GOF-mönster så händer det att jag implementerar dem med beskrivande klassnamn, för det snabbt ska ses vad klassen gör. Men att döpa en assembly med Layer stör jag mig på, tycker inte om det helt enkelt. Har en del större applikationer som är skapade för några år sedan då jag och övriga på avdelningen hade blivit nyfrälsta av Evans, frälsningen finns i stora delar kvar dock inte Layer som suffix :)
Ser ingen skillnad på att lägga till patterns namn i en klass som Layer på en assembly för att göra dess inkapsling av domän-lagret tydligare.. Vi kan också skapa namn efter vad saker gör inte vad dom ligger i, det är ett val vi själva gör.. viktigt att vi använder namn vi känner oss bekväma med och andra kommer att förstå.. vi alla har inte skrivbordet organiserat på samma sätt eller filer på disk.. vi tycker olika, vi har olika smaker etc... och det ska vi ha.. för om alla skulle vara lika så skulle nog världen se rätt knepig ut..
Ja jag har förmodligen blivit så blind av att alltid se dem där så för jag bryr mig inte om att människor som inte har sett dessa projekt innan inte ser det som lika uppenbart, vilket man kan tycka är fel kanske :) Nej denna diskussion är lite för mycket äpplen och päron just nu, själv skyldig till det så nu väntar lite migrering till fluent nhibernate i en gammal app :)
Fredagsskål!
Till något helt annant som absolut inte borde postas här...
Ghlad och Erka och alla andra från Lund trakten.. jag ska ner till Malmö på söndag, och vara där tills på tisdag.. kanske någon som efter detta långa äventry med namn vill träffas för att bara snacka skit eller vad som i Malmö på söndag kväll eller måndag?
Bara droppa ett mail ASAP till fnormen(a)hotmail.com
Som med allt annat här i världen så är vi alla olika och gillar olika saker. Det är därför alltid kul att diskutera olika lösningar med andra, för att hitta nya infallsvinklar och lösningar på problemen.
Jag tycker dock att tråden har gått från konkreta exempel på hur man bör implementera en arkitektur (vilket inte ens var ursprungsfrågan, då den var mer specifik) till att diskutera namn på olika delar av arkitekturen. :)
Jag måste dock tillägga att det är härligt och se er kämpa för era lösningar, när vi alla redan vet att MIN ÄR RÄTT :birp
- M
Jisses vilken fart det blev här :)
jag har lyckats få lite mer ordning i mitt projekt nu, iaf så är vissa klasser betydligt renare än innan. Därmed inte sagt att de är optimala ;)
Nu snubblade jag över ytterligare en liten fundering
En produkt har ju retts ut hur den "bör" se ut (tror jag)
Men i ett specifikt fall här så har jag en produkt som skall visas enligt följande
Titel
Info
Pris
Vilken kategori den tillhör
*sen kommer det knepiga*
Varje produkt har ett antal "variationer" dessa är i grunden kombinationer av färg och modell/storlek (samma princip egentligen)
Till varje produkt hör dessutom ett antal "imagesets", dvs en uppsättning produktbilder för, i det här fallet, de olika färgerna.
Färgvarianterna skall listas som en rad med ikoner som symboliserar färgen medans storlekarna/modellerna skall visas i en dropdown.
(för att göra det ännu "roligare" så har då produkten ett antal relaterade produkter
men detta hör ju definitivt inte till produkten utan dessa får man göra ett separat uppslag av)
min högst tillfälliga lösning på detta är en klass som har propparna
MainProduct, product
Colours, Ienumerable(of Colourcode)
Models, Ienumerable(of Model)
någon kommer säkert gå i taket över denna lösningen ;)
Uppenbarligen måste jag ju "hämta om" produkten varje gång besökaren byter färg eller modell, eftersom det inte är säkert att alla färger finns i alla modeller och tvärtom (idiotsystem)
Din lösning behöver inte alls vara kass, kan vara utmärkt för att lösa ditt spesifika problem baserat på faktorer, så som prestanda, skalbarhet etc.
En Produkt i olika sammanhang i en applikationen kan se olika ut, man pratar ofta om Bounded Context i tex Domain Driven Design. Tex en Produkt för visning är inte samma some ligger i en Order eller på en faktura.. för en Produkt som befinner sig i en order finns i ett annat context och där ska tex inte alla egenskaper finnas, tex där skulle jag haft Modell och Color som egenskap direkt på Produkten.
Ska du tex använda AJAX så kan du tex hämta färger baserat på modellen du valt för en specifik produkt separat, eller för att få upp prestanda, ladda dom i förväg. Allt beror på dina skalbarhets och prestanda mål mm.
Jo min 'Product' har ju egenskaperna Model och Colour, men i just denna context så är det ju själva produktinformationen man vill åt, när kunden sedan väl valt färg och modell så vill man ju kunna visa detta på ett enklare sätt i tex varukorgen
Produkt134, lagomstor, blå 1 st ..
Jo det blir nog nån form av ajax-lösning för att hämta fram modeller/färger/bilder i det här läget egentligen skulle det optimala kanska vara att hämta ut alla varianter och sen hantera allt på klientsidan med js och endast ha en validering serverside
rhdf skrev:
någon kommer säkert gå i taket över denna lösningen
Inte i taket kanske men lösning känns lite väl "hårdkodad" vilket kan vara ok ibland men oftast inte! :)
Det hänger på förståss om du vill kunna nyttja produktklassen till andra shoppar eller inte.
Vill du kunna det så är kanske en class Colours inte så fiffigt. Och heller inte ha en klass för varje sak som skiljer modellerna åt, då slutar man kanske med en produktklass som har: Colours, Sizes, Powers, Heights, Widths ... beroende på vad det är för produkt.
Jag sitter själv i samma funderingar men har ingen färdig design över hur jag vill ha det men det lutar åt nån typ av attributklass, lite mer generisk klass som sedan innehåller de olika attributen.
Blir intressant å se om någon har en bra design för detta! :)
rhdf skrev:
Jo min 'Product' har ju egenskaperna Model och Colour, men i just denna context så är det ju själva produktinformationen man vill åt, när kunden sedan väl valt färg och modell så vill man ju kunna visa detta på ett enklare sätt i tex varukorgen
Produkt134, lagomstor, blå 1 st ..Jo det blir nog nån form av ajax-lösning för att hämta fram modeller/färger/bilder i det här läget egentligen skulle det optimala kanska vara att hämta ut alla varianter och sen hantera allt på klientsidan med js och endast ha en validering serverside
Ofta när jag använder mig av DDD så brukar inte modellen bli den perfekta för presentation, så jag brukar använda mig av en specifik modell för presentation. Jag brukar säga att det är en "variant" av Presentation Model. Sedan när AJAX kommer in i bilden så kan val av design variera från vad man önskade. Så ibland är det helt ok att hålla sig till KISS (Keep it simple stupid). Eftersom färgen på en produkt styrs av modellen så skulle jag koppla samman modell och färg, och inte ha två egenskaper på Produkt, alltså inte Product.Colors, Product.Models.. utan Product.Models bara. Om dina produkter via ett givet context behöver en relation till andra produkter, så skulle jag ev överväga att ha med en egenskap så som RelatedProducts på min specifika context Product klass. Sedan köra med load span. Ev KISS och begära relaterade produkter via ett API, beror på hur och när RelatedOProducts kommer användas.. är det ofta >60%, så skulle jag nog valt en egenskap på Product.. om mindre, ladda dom "on demand" via ett API.
Skulle jag bara visa en produkt och dess modeller och färger,tex när jag ska välja en produkt som jag kan läggas ner i en kundvang, så skulle jag ev idag valt AJAX och hämtat modeller och färger separat via en WCF, Page Method eller WebService (OBS! Om det bara är en vy i min app som är intreserad av att visa modeller och färger).. eller om jag skulle visa flera produkter åt gången och kunna se modeller och färger i den vyn, så skulle jag laddat allt från början och använt DHTML, precis som du nämnde. Fördelen att använda en "Presentation Model" är att den speglar ditt UI och då kan du ladda all den data som ska till vyn och fylla din presentations modell. Jag kör ofta med denna typ av lösning pga att min domän modell är inte anpassad efter ett specifikt UI, och det ska den inte vara.
Om du vill läsa om Bounded Context och varför det kan vara viktigt att ha flera varianter av en entitet baserat på dess context, så kan du ta en titt i Eric Evans bok Domain Driven Design under "Strategic Design". Kan ta ett exempel, om du tar en faktura, så är det ett "papper" som någon får. På detta har du tex Produkt ID, namn, antal och pris.. väldigt lite information. Det är inte en Produkt som ligger på fakturan, utan bara information som är uttagen för just fakturan. I detta fall "återanvänder" man oftast inte en Product entitet, utan skapar en ny för just det specifika context. Fakturahanteringen i en app kan också vara ett subsystem och varje subsystem har sin egna modell.
Sitter på flygplatsen nu, ska till Malmö om 5 min, återkommer senare med mer info när jag har landat och är redo för lite mer internet action ;)
doggelito skrev:
Jag sitter själv i samma funderingar men har ingen färdig design över hur jag vill ha det men det lutar åt nån typ av attributklass, lite mer generisk klass som sedan innehåller de olika attributen.
Blir intressant å se om någon har en bra design för detta!
Jag har även funderat på detta då jag har samma problem i en app som jag håller på med. Jag har både Färger och Material men även information som mått och paketmått och annan beskrivande information.
Jag har försökt hitta någon generics lösning på detta, men alltid är det något som fallerar. Typ att man har en hirarkilösning. Där man kan skriva in Färg som "Header" och sedan de olika färgerna som subitems till denna header och likadant på Material och Mått och Paketmått. Verkar ju fungera bra, men sedan upptäcker man att färgen skall ha information om exakt vilken färg det är den är bara inte blå, utan det skall finnas med en Pantonekod också... Jaja det får väl bli en subitems till färg då, men helt plötsligt så får vi en key-value item här... ja det går ju att lösa...
Så tar vi Storleken på paketet (kartongen) ja där är nu key-value par och det fungerar ju, men sista så vill vi ju ha redan på hur stort detta paket är i kubikmeter, och det är ju beroende av de andra värdena som höjd, bredd och djup..
Så ju mer jag tänker på en generisk lösning, ju mer inser jag att det kommer bli en grymt komplicerad lösning... Så jag har lagt ner det och inset att det får bli specifika klasser för specifika uppgifter
- M
Det är lätt att säga att jag kör med KISS, men det är inget man ska eftersträva, ha det som ett sista alternativ, men som Magnus Ghlad nämner så kan det bli kompliserat att få till en perfekt lösning som också är generisk. I dessa fall så kan KISS vara en räddning. Jag har funderat lite på din fråga. Är det inte så att du har ett unikt artikel-nummer (Produkt id) baserat på modell och färg? I ett system som jag var med och skapade hade ett EAN nummer för varje modell och färg på en produkt. Ser man ganska ofta på Internet, tex en MacBook som är svart har annat artikelnummer än en som är vit. Om samma sak gäller för dig, Så är alla modeller och även på färg nivå en egen produkt. Jag skulle då anse att dom skulle hanteras som en egen separat produkt. Då har Produkt egenskaperna Color och Size. Sedan vill du ev samla alla produkter som relateras till varandra. Finns olika lösningar att smala objekt, ett sätt är att ha ett gemensamt id för alla produlkter som tillhöra varandra, tex:
produkt.RelatedProductId
Där RelatedProductId är samma för alla produkter som hör tillsammans.. tex Säg att du säljer en viss tröja, där tröjan kan variera i storlek och färg, du vill kanske då samla alla tröjor som hör ihop med hjälp av ett gemensamt id. Men du vill hanterar alla som egna unika produkter. Om du kör med LINQ så har du ganska lätt för att gruppera ihop produkterna etc. Detta kan vara en tänkbar lösning, om det nu är så att du har ett unikt artikel-nummer per modell och färg..
I mitt fall är det så att en "produkt" egentligen är flera ;)
dvs varje kombination av modell /färg hanterar jag som en egen produkt med ett eget ID/artikelnummer
De relaterade produkterna har dock inget med produkten att göra, förutom att shop-ägaren anser att de passar med varandra (exempelvis i en klädshop där man rekommenderar ett antal accessoarer till en ett plagg)
rhdf skrev:
I mitt fall är det så att en "produkt" egentligen är flera ;)
dvs varje kombination av modell /färg hanterar jag som en egen produkt med ett eget ID/artikelnummerDe relaterade produkterna har dock inget med produkten att göra, förutom att shop-ägaren anser att de passar med varandra (exempelvis i en klädshop där man rekommenderar ett antal accessoarer till en ett plagg)
Håller med här.
Jag har själv lite svårt att se var relatedproductid är. Dock kan jag förstå om en produkt är av en viss typ så som T-Shirt och man via det kan gruppera alla T-Shirts som är egna produkter.
Skall man va extra jobbig har vi ju EAN-Nummer, batchnummer, VAT-nummer allt det där jobbiga som oxå via vissa nummerserier kan höra ihop.
Livet är inte lätt :)
