32 svar · 1 817 visningar · startad av Travoni · sida 2 av 2
Om man har ett DAL och en BLL-klass, skall man då lägga underklasser i den BLL:en eller skall man skapa fler BLL:er? Ex. Class BLL Class Users End Class Class Tags End Class 'osv End Class [red][B]Eller:[/B][/red] Class BLLUsers End Class Class BLLTags End Class 'osv
Läs frågan i sin helhet →Gladh skrev:
nickemannen skrev:
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.
- M
Ja du har rätt min domän är affärslogik, men jag vill inte dela in det så hårt som:
GUI
BLL
DAL
Hmm svårt att förklara :| men det är väldigt lika som du säger.
nickemannen skrev:
Ja du har rätt min domän är affärslogik, men jag vill inte dela in det så hårt som:
Det förstår jag. Själv tycker jag det gått lite troll i alla de olika "utvecklingsmetoderna". Känns nästan som det har uppfunnits för att "de lärde" skall ha något att diskutera om. I slutändan så handlar det ändå alltid om att dela upp sina applikationer i olika lager för att underlätta vidarutveckling och underhåll av koden.
Själv har jag lämnat "DDD-tänket" lite för att mer fokusera på entiteter som databärare och olika lager som opererar på dessa entiteter. Jag vill helt enkelt inte ha någon logik i mina klasser, utan de skall bara beskriva hur klassen ser ut (domän-lager), inte vad den kan göra, det får en annan klass (BLL) göra istället.
Rätt eller fel? Tja jag trivs med det eftersom jag slipper mappa ihjälp mig när entiteterna skall skickas mellan olika lager och services....
För lite av problemet med "äkta" DDD är ju att din GUI/DAL inte skall kunna accessa dina metoder i dina domänklasser utan bara datan. Så iprincip så skall du ha dels en vanlig User-klass som innehåller all data och alla operationer, och sedan skall du ha en UserLight-klass som bara innehåller data som du skickar mellan de olika lagrerna och skall man dessutom anropa en services någon annanstans så skall den servicesen user-entitet mappas till din userlight-klass som sedan skall mappas mot din User-klass. *puhhhh*
Så antingen följer man rekomendationerna slaviskt eller så är man lite pragmatiskt och bryter mot de när man kan och följer de när det behövs. Själv så hade jag nog lagt min UserLight-klass i min User-klass och om jag velat komma åt data i User-klassen så skulle jag kallat så här.
string name = myUser.UserLight.Name;
För då hade jag sluppit mappningen mellan User och UserLight klassen och har bara mappningen mellan UserLight och Userentiteten kvar, och för att minska även på den hade jag nog gjort något liknanden där...
Men det är mest för jag är LAT...
- M
Gladh skrev:
nickemannen skrev:
Ja du har rätt min domän är affärslogik, men jag vill inte dela in det så hårt som:
Det förstår jag. Själv tycker jag det gått lite troll i alla de olika "utvecklingsmetoderna". Känns nästan som det har uppfunnits för att "de lärde" skall ha något att diskutera om. I slutändan så handlar det ändå alltid om att dela upp sina applikationer i olika lager för att underlätta vidarutveckling och underhåll av koden.
Själv har jag lämnat "DDD-tänket" lite för att mer fokusera på entiteter som databärare och olika lager som opererar på dessa entiteter. Jag vill helt enkelt inte ha någon logik i mina klasser, utan de skall bara beskriva hur klassen ser ut (domän-lager), inte vad den kan göra, det får en annan klass (BLL) göra istället.
Rätt eller fel? Tja jag trivs med det eftersom jag slipper mappa ihjälp mig när entiteterna skall skickas mellan olika lager och services....
För lite av problemet med "äkta" DDD är ju att din GUI/DAL inte skall kunna accessa dina metoder i dina domänklasser utan bara datan. Så iprincip så skall du ha dels en vanlig User-klass som innehåller all data och alla operationer, och sedan skall du ha en UserLight-klass som bara innehåller data som du skickar mellan de olika lagrerna och skall man dessutom anropa en services någon annanstans så skall den servicesen user-entitet mappas till din userlight-klass som sedan skall mappas mot din User-klass. *puhhhh*
Så antingen följer man rekomendationerna slaviskt eller så är man lite pragmatiskt och bryter mot de när man kan och följer de när det behövs. Själv så hade jag nog lagt min UserLight-klass i min User-klass och om jag velat komma åt data i User-klassen så skulle jag kallat så här.
string name = myUser.UserLight.Name;För då hade jag sluppit mappningen mellan User och UserLight klassen och har bara mappningen mellan UserLight och Userentiteten kvar, och för att minska även på den hade jag nog gjort något liknanden där...
Men det är mest för jag är LAT...
- M
Som du säger inget skall följas slaviskt, det är mer riktlinjer :).
Man får väl ha en egen personlig touch på det eller gruppens personliga touch på det om man arbetar i grupp. :)
Men som du skriver så kan det bli mycket meck med DDD egentligen skall bara den datan exposas som behövs för fallet osv. Går att lösa med interface osv, men det är ganska mycket att sätta in sig i om man inte är intresserad så det är svårt att få över massan.
Gladh skrev:
Själv har jag lämnat "DDD-tänket" lite för att mer fokusera på entiteter som databärare och olika lager som opererar på dessa entiteter. Jag vill helt enkelt inte ha någon logik i mina klasser, utan de skall bara beskriva hur klassen ser ut (domän-lager), inte vad den kan göra, det får en annan klass (BLL) göra istället.
Så gör jag för tillfället, mest för att jag är lat! Vill inte gärna in och pilla med partial classes på mina entity framework entities så jag skapar ett lager som får agera entity context. Där sköts all logik och så får man det snyggt strukturerat i intellisense. GetEntity(int entityID), GetEntities(), CreateEntity() osv.
proxy-klasserna blir ju lite stora men det känns bättre att göra såhär än något annat sätt jag prövat. Visst vore det kul att designa upp en riktigt domän-driven sida / applikation men det är verkligen inget jag tänker göra själv då det tar för lång tid. Föredrar helt klart att göra...
public class UserProxy
{
private UserEntities context = new UserEntities();
internal UserProxy(){}
/// <summary>
/// Creates the user.
/// </summary>
/// <param name="first">The first.</param>
/// <param name="last">The last.</param>
/// <param name="email">The email.</param>
/// <param name="age">The age.</param>
internal void CreateUser(string firstName, string lastName, string email, string age)
{
Users user = new User();
user.FirstName = first;
user.LastName = last;
user.Email = email;
user.Age = age;
context.SaveChanges();
}
/// <summary>
/// Gets all users
/// </summary>
/// <returns>List of users</returns>
internal IList<Users> GetUsers()
{
var query = from u in context.Users
select u;
return query.ToList();
}
}
Blir det någon betydande prestandaförlust om man har en assembly jämfört med tio? Tio kontra hundra etc?
Hur hanteras egentligen "parsningen" av en respektive flera assemblies?
Vet inte om det blir någon jättebetydande, har suttit med en miljö med runt 20 och det tog ett jävla tag dock så var det ganska mycket kod det handlade om men har läste någon artikel för ett tag sedan och jag tyckte det lät vettigt hittade inte den men hittade den som låg ovan här.
Sitter i projekt med ungefär 20 assemblyn för tillfället. Dock så kör jag bara unload på de assemblyn som inte är av intresse under tiden jag utvecklar. Vi har ett antal tunna klienter som har sitt assembly. Huvudprogrammet har sitt assembly. PLC trafiken har sitt assembly, loggern sitt osv i all förbannad assembly. Skulle inte vilja ha det på något annat sätt för det skulle betyda att jag fick håla på med ctrl+x, ctrl+v för mycket.
Återanvändingsbarhet FTW!
CatZ skrev:
Sitter i projekt med ungefär 20 assemblyn för tillfället. Dock så kör jag bara unload på de assemblyn som inte är av intresse under tiden jag utvecklar. Vi har ett antal tunna klienter som har sitt assembly. Huvudprogrammet har sitt assembly. PLC trafiken har sitt assembly, loggern sitt osv i all förbannad assembly. Skulle inte vilja ha det på något annat sätt för det skulle betyda att jag fick håla på med ctrl+x, ctrl+v för mycket.
Återanvändingsbarhet FTW!
Självklart skall man inte ta bort assemblies som verkligen behövs för projektet.
Men sedan kanske inte loggerprojektet t.ex. måste vara i källkod utan den kanske du redan kan ha förkompilerad och med referens.
jo, den behöver ju inte debuggas. Jag har den inte som projekt referens utan som referens till dll. Loggern kraschar inte så det finns ingen anledning att debugga den. Jag vet vad som händer när det inträffar fel och jag vet var det loggas ;)
Har alltid haft problem med hur jag skall namnge mina namespaces och klasser, för att göra dem så beskrivande som möjligt.
Har börjat gå mot denna form av namngivning.
[Projektnamn].Core
Mina entitetklasser (kärnan i applikationen) och deras samtliga interfaces.
som nyttjas av dem klasserna utanför kärnan.
[Projektnamn].Core.Repository
En annan del av kärnan som i stort bara säga hur de repositortyklasserna som används vid hämtning av data, vilka metoder dessa MÅSTE innehålla. Består av interfaces.
[Projektnamn].Infrastructure.Services
Här finns diverse olika klasser, metoder etc som inte passar ihop konceptuellt med något specifikt domänobjekt.
[Projektnamn].Infrastructure.Repositories
Mina repository klasser som returnerar objekten med dess data.
[Projektnamn].UI.Win
För Windowsapplikationer
[Projektnamn].UI.Web
För Webapplikationer
[Projektnamn].UI.PDA
För Winapplikationer på PDA's. Dock är de övriga filerna anpassad till Compact .NET framework.
Ex. på nyttjandet av mina repositories kan vara:
OrderRepository orderrepo = new OrderRepository();
// Tycker den är rätt så självbeskrivande.. :)
List<IOrder> orders = orderrepo.GetOrdersByCustomerNumber(customer.Number);
[Projektnamn].UnitTests
Har börjat smaka lite på testdriven developement. Lite småkul faktiskt.. :)
Givetvis återfinns en form av DAL (Data access layer), givetvis återfinns en form av BLL (Business logic layer). Dock används en annan form av namngivning för att försöka ge en beskrivning av vad som händer i koden på ett självbeskrivande sätt. (jag försöker i alla fall, är ju ingen expert) :)
Dock vilja försöka få så att databaser, xml-filer och så vidare inte hamnar i centrum som de alltid har varit för mig. Utan snarare att min Core "domänmodell" hamnar där.
OrderRepository orderrepo = new OrderRepository();
// Tycker den är rätt så självbeskrivande..
List<IOrder> orders = orderrepo.GetOrdersByCustomerNumber(customer.Number);
Är inte Order i GetOrdersByCustomerNumber lite för mycket info, du har ju redan sagt att du skall hämta orders med orderRepository eller kan den skicka tillbaka något annat än orders?
Hmm det som du beskriver ovanför. är det namespaces eller är allt uppdelat i assemblies?
[Projektnamn].Core
Mina entitetklasser (kärnan i applikationen) och deras samtliga interfaces.
som nyttjas av dem klasserna utanför kärnan.
[Projektnamn].Core.Repository
En annan del av kärnan som i stort bara säga hur de repositortyklasserna som används vid hämtning av data, vilka metoder dessa MÅSTE innehålla. Består av interfaces.
Känns ju som att du inte behöver ha dom två i olika assemblies.
Nickemannen skrev:
OrderRepository orderrepo = new OrderRepository();
// Tycker den är rätt så självbeskrivande..
List<IOrder> orders = orderrepo.GetOrdersByCustomerNumber(customer.Number);Är inte Order i GetOrdersByCustomerNumber lite för mycket info, du har ju redan sagt att du skall hämta orders med orderRepository eller kan den skicka tillbaka något annat än orders?
Hmm det som du beskriver ovanför. är det namespaces eller är allt uppdelat i assemblies?
[Projektnamn].Core
Mina entitetklasser (kärnan i applikationen) och deras samtliga interfaces.
som nyttjas av dem klasserna utanför kärnan.[Projektnamn].Core.Repository
En annan del av kärnan som i stort bara säga hur de repositortyklasserna som används vid hämtning av data, vilka metoder dessa MÅSTE innehålla. Består av interfaces.Känns ju som att du inte behöver ha dom två i olika assemblies.
Så här tänker jag,
[Projektnamn].Core är ett assembly (där ingår givetvis Repository)
Ex. Malmstroem.Core.dll
[Projektnamn].Infrastructure (är ett annat assembly som refererar Core, i och med att ibland kan det röra sig om databas, ibland xml-filer, ibland kanske rent av web services som datakälla. ibland en blandning..) g.
Ex. Malmstroem.Infrastructure.dll
Jo ang:
OrderRepository orderrepo = new OrderRepository();
// Tycker den är rätt så självbeskrivande..
List<IOrder> orders = orderrepo.GetOrdersByCustomerNumber(customer.Number);
Så har jag givetvis inte riktigt slagit mig lös från bad behaviors än. :OO
Har fortfarande lite problem att slå mig fri från att inte sätta databasen i centrum också.. :e
Hör ordet Refactor i susa i huvudet nu..
Givetvis skall det vara
List<IOrder> orders = orderrepo.GetByCustomerNumber(customer.Number);
eller för enstaka specifik order
IOrder orders = orderrepo.GetByKey(order.Key);
Ibland blir det kaka på kaka. :) Men kaka är gott.. speciellt chockladkaka.
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.
Usch för regioner, de bara smutsar ner, förstår inte ens hur de kom till. Bara vetskapen om dem skapar ju smutsig kod.
Jo jag vet vi gömmer vår dåliga kod under en region som säger vad vi gömmer för kod så slipper folk se den? Eller jaaaaa vi skapar 5000 rader klass och kapslar in saker i regioner så känns den inte så stor... HURRA!!! Skål :birp
nä hehe.. ;) :l men ärligt, vad skall man med dem till? Finns nog inget mer störande än regioner i kod som man måste pluppa upp o ner... de tillför faktiskt ärligt talat ingen nytta alls. Kom inte o säg jo för man kan då gömma undan viss oviktig kod typ. Vad då oviktig? all kod är ju viktig... :P
varför gömma den... :e
:birp :birp :bire :stud :i §e (n)
Fredde mannen... :
hehe coolt namn, min bror heter fredrik mkt fredde var det.. :)
Så här tänker jag,
[Projektnamn].Core är ett assembly (där ingår givetvis Repository)
Ex. Malmstroem.Core.dll
[Projektnamn].Infrastructure (är ett annat assembly som refererar Core, i och med att ibland kan det röra sig om databas, ibland xml-filer, ibland kanske rent av web services som datakälla. ibland en blandning..) g.
Ex. Malmstroem.Infrastructure.dll
jag som gillar DDD brukar ha egna projekt för mina repositories och sen ett projekt för min domän och ibland även för services och factories men alla delar en gemensam nämnare de går under domänlagret. Att de ligger i olika projekt har inget med lager att göra i mina system. Lager är mer en designstruktur hur jag pratar mot dem. Hur de avgränsar mellan varandra.
Core är ett ok namn, det medelar att här är kärnan vilket domänlagret är. Dock nyttjar jag personligen oftast Core ordet i Infrastructuren som mer eller mindre är core features som mina andra projekt sedan delar på. Men det är lite smaksak, viktigast är bara att alla i teamet vet vad order betyder för gruppen.
Mvh Johan