Nu kan jag bara prata för hur jag gör (men givetviss så gör jag rätt ;) ).
Jag skapar en assembly (alltså ett projekt i VS) och döper det till. Typ
[FÖRETAGS_NAMN].[PROJEKT_NAMN].Backend.Business
Där i så skapar jag mina klasser, och varje klass är en egen .cs-fil. Alltså inte 2 klasser i samma fil (om det inte är en privat klass till den klassen)
Så det blir att så så här:
i filen user.cs
namespace [FÖRETAGETS_NAMN].[PROJEKTETS_NAMN].Backend.Business
{
public class User{ ... }
}
i filen tags.cs
namespace [FÖRETAGETS_NAMN].[PROJEKTETS_NAMN].Backend.Business
{
public class Tags{ ... }
}
Så varje lager i projektet blir ett eget assembly...
Jag gillar inte namnen DAL eller BLL osv det känns föråldrat.
Jag vet inte heller om jag tycker att man bör dela upp allt i olika assemblies, det beror lite på hur vad det är för system, hur stort det kommer att bli och andra krav, det kan lika gärna ligga i samma assemblie under något dll:en som ni beskrivit ovan.
[FöretagetsNamn].[ProjektetsNamn].Persistence
Jag tycker att man bör lägga modellen direkt under [FöretagetsNamn].[ProjektetsNamn] för att då kommer alla andra namespace åt t.ex. Customer utan att behöva använda using osv som t.ex. inuti Persistence namespacet behöver vi inte använda using för att få tag på Customer.
Presentationen om det nu är Winform eller Web så tycker jag att det skall separeras i assemblies däremot.
Vinsten med detta är, vi slipper onödigt många assemblies. (reducerar byggtid).
Är det så att man vill ha en ny assembly som skall vara separerat, ja då tycker jag att denna skall ha kännedom hur den registrerar sig hos "huvudassemblyn" så att den kan använda samma persistens logik om den inte vill använda sin egen.
Det sista blev kanske lite komplext.
Jag tycker att BLL, DAL går emot DDD som jag gillar :).
Ex
[FöretagetsNamn].[ProjektetsNamn] - Objektmodell/domänlager
[FöretagetsNamn].[ProjektetsNamn].WebClient - ASP.NET MVC Application
[FöretagetsNamn].[ProjektetsNamn].WebService - ASP.NET Web Service
[FöretagetsNamn].[ProjektetsNamn].WinClient - Windows Forms/WPP Application
Företagsnamn.ProjektNamn.TypAvLager - Modell, WebUI, WinUI.
FöretagsNamn.PlcKommunikation - (denna är i princip samma för alla projekt och är det något projekt som sticker ut här så finns det modifierat här utan att göra ändringar för de övriga projekten.)
Företagsnamn.Logging - Denna har jag behov av i alla projekten och har den i ett eget problem för att slippa "circular references." (Alla övriga projekt kan använda denna)
Företagsnamn.Utilities - Återigen ett projekt som är gemensamt för många andra.
Eftersom jag tagit till mig Entity Framework så arbetar jag inte direkt mot den utan skapar proxy-klasser som får sköta all logic mot modellen. Jag börjar få till det rätt bra faktiskt. Jag har varken tid eller möjlighet att DDD-programmera bättre än så även om jag skulle vilja.
Det var väl inte riktigt din fråga kom jag på nu! :) Tidigare så har de lag klasser jävligt huller om buller lite hur som helst, det har jag rått bot på.
Jag satt i förra projektet med en Winform.cs på 5000 rader kod. DET ÄR FEL! Särskilt med logiken kan det bli rätt stort om man inte tänker rätt från början och den vill du lyfta ut till många små klasser istället. Du kan ju tex använda dig av partial i C# eller Shared i VB. Vill du envisas med att ha allting i en fil så rekommenderar jag dig att dela upp funktionerna i olika #region så det blir lätt att kollapsa hela filen. ctrl+m, ctrl+m & ctrl+m, ctrl+o är din vän :)
Det var väl inte riktigt din fråga kom jag på nu! :) Tidigare så har de lag klasser jävligt huller om buller lite hur som helst, det har jag rått bot på.
Jag satt i förra projektet med en Winform.cs på 5000 rader kod. DET ÄR FEL! Särskilt med logiken kan det bli rätt stort om man inte tänker rätt från början och den vill du lyfta ut till många små klasser istället. Du kan ju tex använda dig av partial i C# eller Shared i VB. Vill du envisas med att ha allting i en fil så rekommenderar jag dig att dela upp funktionerna i olika #region så det blir lätt att kollapsa hela filen. ctrl+m, ctrl+m & ctrl+m, ctrl+o är din vän :)
Usch, har man 5.000 rader i en klass har man oftast gjort något kraftigt fel anser jag.
Om det är winform's så tenderar ju filen att bli stor men då kanske det är dags för usercontrol's?
Annars är det bara dålig uppdelning.
De flesta klasser jag skapar innehåller mellan 20-500 rader, mestadels runt 30-100 för domänentiteter och 100-200 där det ligger lite mer logik i domänobjekten.
Det var väl inte riktigt din fråga kom jag på nu! :) Tidigare så har de lag klasser jävligt huller om buller lite hur som helst, det har jag rått bot på.
Jag satt i förra projektet med en Winform.cs på 5000 rader kod. DET ÄR FEL! Särskilt med logiken kan det bli rätt stort om man inte tänker rätt från början och den vill du lyfta ut till många små klasser istället. Du kan ju tex använda dig av partial i C# eller Shared i VB. Vill du envisas med att ha allting i en fil så rekommenderar jag dig att dela upp funktionerna i olika #region så det blir lätt att kollapsa hela filen. ctrl+m, ctrl+m & ctrl+m, ctrl+o är din vän :)
Angående region så tycker jag Jeff Atwood har en bra poäng!
Företagsnamn.ProjektNamn.TypAvLager - Modell, WebUI, WinUI.
FöretagsNamn.PlcKommunikation - (denna är i princip samma för alla projekt och är det något projekt som sticker ut här så finns det modifierat här utan att göra ändringar för de övriga projekten.)
Företagsnamn.Logging - Denna har jag behov av i alla projekten och har den i ett eget problem för att slippa "circular references." (Alla övriga projekt kan använda denna)
Företagsnamn.Utilities - Återigen ett projekt som är gemensamt för många andra.
Eftersom jag tagit till mig Entity Framework så arbetar jag inte direkt mot den utan skapar proxy-klasser som får sköta all logic mot modellen. Jag börjar få till det rätt bra faktiskt. Jag har varken tid eller möjlighet att DDD-programmera bättre än så även om jag skulle vilja.
Japp sådant är ju vanligt :). Det är sådana saker man bör lagra i andra assemblies. Komponenter som skall sträcka sig över flera produkter annars är det oftast ganska onödigt.
okej att man snabbt vill byta ut sin metod att ansluta till databas t.ex. men vad hindrar att ändra det i assemblien direkt och kompilera om, i de flesta fall är det inga problem. I andra fall kanske man bör lägga det utanför men då bör assemblynamnet beskriva hur, t.ex.
Företagsnamn.Produkt.NHibernateRepositorys / Företagsnamn.Produkt.NHibernatePersistence
Angående region så tycker jag Jeff Atwood har en bra poäng!
Det finns många som tycker att man inte skall använda sig av regioner.
Jag har delad åsikt, om det skall användas skall det användas på rätt sätt. Men jag lutar nog mer till att man ej bör använda det. Men vid långa defintionslistor tycker jag det är okej.
Dock så tycker jag inte om Jeff's första punkt som han skrev i den artikeln.
Folding directives are glorified comments. #region has zero meaning to the compiler; it's a hint to the editor to allow code folding. It doesn't do any namespacing or scoping. Why, exactly, are we writing code to accommodate the editor? It boggles my mind that we'd add significant lines of code to our project that do nothing but offer organizational hints to the editor. Even traditional comments are a better value for your keystroke, because they can be more expressive. And folding is certainly no substitute at all for bona-fide refactoring.
Här skriver han hur #region's inte har något med kompilern att göra, men det är ju egentligen inte kompilern som är i fokus utan hur vi gör våran kod mer lättläst/lätarbetad.
Även om nu regions inte hjälper där. Och att region's betyder en massa mer rader tycker jag inte heller är så viktigt.
Jag satt i förra projektet med en Winform.cs på 5000 rader kod. DET ÄR FEL! Särskilt med logiken kan det bli rätt stort om man inte tänker rätt från början och den vill du lyfta ut till många små klasser istället. Du kan ju tex använda dig av partial i C# eller Shared i VB.
Inte för att vara sån, men en klass på 5000 rader är en klass på 5000 rader, oavsett om den består av en fil på 5000 rader eller om den består av 10 filer á 500 rader. ;) Partial classes ska inte användas för att strukturera kod, utan för att skilja automatgenererad kod från handskriven kod.
Inte för att vara sån, men en klass på 5000 rader är en klass på 5000 rader, oavsett om den består av en fil på 5000 rader eller om den består av 10 filer á 500 rader. ;) Partial classes ska inte användas för att strukturera kod, utan för att skilja automatgenererad kod från handskriven kod.
Det finns många som tycker att man inte skall använda sig av regioner.
Jag har delad åsikt, om det skall användas skall det användas på rätt sätt. Men jag lutar nog mer till att man ej bör använda det. Men vid långa defintionslistor tycker jag det är okej.
Dock så tycker jag inte om Jeff's första punkt som han skrev i den artikeln.
Folding directives are glorified comments. #region has zero meaning to the compiler; it's a hint to the editor to allow code folding. It doesn't do any namespacing or scoping. Why, exactly, are we writing code to accommodate the editor? It boggles my mind that we'd add significant lines of code to our project that do nothing but offer organizational hints to the editor. Even traditional comments are a better value for your keystroke, because they can be more expressive. And folding is certainly no substitute at all for bona-fide refactoring.
Här skriver han hur #region's inte har något med kompilern att göra, men det är ju egentligen inte kompilern som är i fokus utan hur vi gör våran kod mer lättläst/lätarbetad.
Även om nu regions inte hjälper där. Och att region's betyder en massa mer rader tycker jag inte heller är så viktigt.
Nej, det kanske är fjantigt att haka upp sig på att #region och #endregion är onödiga kodrader för att de inte har någon mening för kompilatorn men hans poäng är ju att kommentarer lika gärna kan användas för att strukturera och göra kod mer lättläst.
Jag brukar använda regions om jag har en kontroll med många properties som jag vill gömma eller om jag vill gömma event handlers. Ibland är det svårt att undvika stora kodmassor i t.ex. winforms och då kan det vara skönt att få bort en del kod (ungefär som VS delar upp en form med partial.)
Nja jag håller inte med dig spango, det är omöjligt att göra någon vettig refactoring i en 5000rader lång fil. Det är lättare om man flyttar ut så mycket man kan av det som inte borde ligga i den filen så att man kan normalisera koden.
Nu är det inte mer än ca 1000 rader kod på några olika filer. Alltså hade vi 4000 rader onödig kod i en fil. Då är det inte lätt att När jag sa 5000 rader kod så menade jag bara i code behind.
Nej, det kanske är fjantigt att haka upp sig på att #region och #endregion är onödiga kodrader för att de inte har någon mening för kompilatorn men hans poäng är ju att kommentarer lika gärna kan användas för att strukturera och göra kod mer lättläst.
Jag brukar använda regions om jag har en kontroll med många properties som jag vill gömma eller om jag vill gömma event handlers. Ibland är det svårt att undvika stora kodmassor i t.ex. winforms och då kan det vara skönt att få bort en del kod (ungefär som VS delar upp en form med partial.)
Precis så jag gör. Alla mina buttons och events sköter egentligen ingenting. All logik brukar jag göra egna metoder till och bara gömma alla DagaGridView event och övrigt. Anledning är att för att göra korrekt så ska alla protected metoder dokumenteras och eftersom de ska dokumenteras för att vara compliant så blir det massa jäkla onödig kod som jag aldrig vill se :) Därför gör jag privata logik-metoder som jag arbetar i. Kanske är annorlunda om man arbetar flera stycken i ett projekt.
okej att man snabbt vill byta ut sin metod att ansluta till databas t.ex. men vad hindrar att ändra det i assemblien direkt och kompilera om, i de flesta fall är det inga problem. I andra fall kanske man bör lägga det utanför men då bör assemblynamnet beskriva hur, t.ex.
Företagsnamn.Produkt.NHibernateRepositorys / Företagsnamn.Produkt.NHibernatePersistence
Håller med fullständigt! Jag har börjat tänka som så att behöver jag ändå kompilera om för att ändringarna ska komma med så kan det lika gärna kvitta.
Med loggningen däremot (som exempel) så vill jag kunna kompilera om och byta ut bara den dll-en utan att behöva riskera att orsaka några problem i det riktiga projektet!
Nej, det kanske är fjantigt att haka upp sig på att #region och #endregion är onödiga kodrader för att de inte har någon mening för kompilatorn men hans poäng är ju att kommentarer lika gärna kan användas för att strukturera och göra kod mer lättläst.
Jag brukar använda regions om jag har en kontroll med många properties som jag vill gömma eller om jag vill gömma event handlers. Ibland är det svårt att undvika stora kodmassor i t.ex. winforms och då kan det vara skönt att få bort en del kod (ungefär som VS delar upp en form med partial.)
Regions är väl en smaksak antar jag :).
Ja det är lätt att mängden i Winforms springer iväg (då menar jag visserligen vs.net automatgenerarade kod som ligger i den partiella klassen men den är egentligen ovisentlig), events kan man oftast hålla ner med en bra modell som är bra bunden mot formulären, men det finns ju alltid specialfall.
Parentes
Mina proxys har en tendens att bli väldigt långa, då är det skönt att folda ihop regioner med olika avgränsade anrop tycker jag, det blir så smidigt att få en översikt över var man ska lägga in sina nya anrop :)
Jag tycker att BLL, DAL går emot DDD som jag gillar .
Hur kan du tycka det, ditt DDD bör ju vara ditt "BLL" och ifrån ditt DDD anropar du till ett DAL. Kalla det vad du vill, men iprincip så är det samma sak.
Hur kan du tycka det, ditt DDD bör ju vara ditt "BLL"
Det håller jag med om, din domän har ju inget med persistence att göra så ett dal-tänk går ju inte emot ett DDD-tänk. Du använder ju DAO eller liknande för att populera dina domänobjekt ofta i en DDD-approach. Hur populera objekt från din domän utan en form av data access-lager
265 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
