Presentations Logik
Code-behind för WebForms, med WinForms får man väl ha något annat?
Business Logic Layer, Business Object Layerordningen på dessa?
Logiken, skapar Business Object dvs basklasser såsom User, Person Movie etc. Business Logic använder sig av Business Data Access för att exempelvis hämta data från en databas och fylla objekten med dessa. Här skulle det även vara bra med "strongly typed collections"?
Business Data Access Layernamn?
Ärver från den generella DataAccess. Metoder såsom GetMovies, GetMovie etc. En Business Data Access representerar alltså en tabell i min databas, dvs bdaMovie
Ser väl rätt bra ut. Jag brukar slå ihop Business Object Layer och Business Data Access Layer om jag förstår dig rätt. Då får jag:
Presentationslager---Business Layer --- Data Layer --- Data Access Layer och sen klämer jag in en O/R mapper mellan också så hos mig blir det:
Presentations Lager
WinForms, WebForms etc
Presentations Logik
Code-behind för WebForms
Business Logic Layer, Business Object Layer
Logiken, skapar Business Object dvs basklasser såsom User, Person Movie etc.
Business Data Access Layer
Ärver från den generella DataAccess. Metoder såsom GetMovie / GetMovies som använder sig direkt av O/R mappern.
O/R Mapper
Innehåller funktioner så som GetObjectById,GetObjectsById,UpdateObject osv.
Data Access Layer
Klasser för DataAccess(mysql,sql,acess etc)
Okej, det där med O/R Mapper låter intressant, använder du en färdig eller en egen?
Hur gör du med exempelvis ditt affärslager, är det ett "class library" som du kompilerar till en dll? Skulle vara intressant att veta hur man kan strukturera upp det i exempelvis Visual Studio. Data Access Layer borde men kunna göra en komponent av som man kan återanvända i många projekt. Med affärslagret så känns det som att det blir ganska specifikt för ett projekt.
Något sådant här tänker jag på:
Presentationslager: Exempelvis ASP.NET projekt
Business Layer: Class library (assembly)
Data Access Layer: Class library (assembly)
Mitt presentationslager känner till min business komponent och min business komponent använder sedan mitt Data Access Layer. Det här är kanske helt fel sätt att tänka?
Har byggt en egen ORmapper, fungerar väl hyffsat, bygger ut den när det behövs. Skicka ett mess om du vill ha källkoden att kolla på.
Försöker alltid dela upp det så mycket som möjligt så om jag någon gång i framtiden t.ex ska byta från "winforms" till "webforms" så ska det fungera. Tycker det låter bra som du skriver, fråga Gladh han har koll på sånna grejer!
Det vore absolut intressant att se hur du byggt upp din ORmapper även om jag bara befinner mig i startgroparna och fortfarande har mycket att lära mig om .net. Skickar dig ett pm senare idag. :)
Sedan får jag hoppas att Gladh får syn på denna tråden eller någon annan som har bra kolla på dessa saker.
Och funderar på om jag skall blanda mig in i disskutionen, det är hyfsat svårt att ta en arkitektur via ett forum, man behöver en whiteborad (request till utvecklarna :) ).
Din arkitektur bör återspegla det behov du har. Och det med utgångspunkt i, utvecklingstid, prestanda, underhåll samt vilken arkitekturmönster som man valt att använda som grund. Alla dessa premisser ger dig sedan en arkitektur att använda.
Själv så håller jag på med serviceorienterade arkitektur och det skiljer sig lite mot OO. Man kan använda OO inne i sina services, men interfacet mot SOA skiljer sig mot OO genom att man använder messages/entiter istället för BO.
jag tycker din uppdelning ser bra ut, det finns givetviss saker att ändra beroend på vad som är viktigt för dig, är det viktigt att man skall kunna ha "plug-and-play" i drift, eller är prestanda viktigt för dig, eller kanske utvecklingshastigheten eller är det möjligheten att kunna gå in och underhålla samt bygga ut ditt system senare. Alla dessa premisser kommer tyvärr att ta ut varandra lite och därför kommer vinst på ett område påverka negativt på ett annat. Men som en gyllene medelväg så tycker jag att din uppdelning är bra, även om jag nog skulle rekomendera dig att använda en ORMapper istället för skriva alla Business Data Access lager själv...
Man får tacka för det informativa svaret. Hela syftet med mitt projekt är att fördjupa mina kunskaper i .net och tillämpa dessa på en lagerbaserad arkitektur. Mitt sikte är inställt att jobba med något liknande, vill minnas att det kallas "affärssystem", när jag avslutat mina studier.
Vet inte riktigt vad jag har mer att tillägga, men det känns hur som helst skönt att jag inte fått all om bakfoten. Litteratur-tips inom dessa områden böcker/msdn osv emottages mer än gärna :)
Compusa, du kan kolla på open source OR/Mappern Hibernate för java som nu finns som stabil .net version NHibernate, personligen tycker jag det ser mycket intressant ut. Det man kan göra är att kolla på många exempel från både sun och microsoft, starterkits, pet-shot etc, även om .net petshopen är lite underlig på sina ställen. En annan sak man kan göra är att kolla på Enterprise Application Block som tillhandahålls av teamet bakom .Net om man vill ha bra uppslag / best practice. Läsa böcker om patterns, gillar personligen Patterns of Enterprise Application Architecture av Addison Wesley.
Just affärstjänster tenderar till att bli mer SOA-orienterade och MSDN har mycket läsvärt om det.
Tack för ditt svar och länken erka. Har ägnat en hel del tid åt att kolla lite open-source applikationer. Det jag kommer att börja med i mitt lilla projekt är att bygga mitt DAL och jag kommer fördmodligen att vänta med OR/Mappern tills jag har lärt mig det andra. Blir lätt lite mycket på en gång annars ;)
Har funderat lite på hur jag ska bygga mitt DAL. Ett populärt tillvägagångssätt verkar vara att bygga en generell DAL som sedan business data access layer ärver ifrån. Detta verkar vara ett ganska smidigt sätt, dock så blir ju bdl ganska så mycket knutet till dalet och man kan behöva ändra sitt bdl vid byte av databas.
Har läst lite om design patterns och tycker det känns som en abstract factory skulle passa ganska bra till min lösning. En tanke är att ha en abstrakt DalFactory som implementeras av DalFactoryMySQL, DalFactoryMSSQL osv. Dessa factories kan sedan skapa mina Business Data Access Layers som implementerar ett gemensamt interface, dvs ett BDL för varje factory... Hittade en variant som verkar fungera som jag tänkt mig. Bilden nedan som kanske förklarar detta lite bättre: http://www.xisc.com/wiki/index.php/Image:Petshop_DAO.gif
Vad tror ni om denna lösningen kontra den jag nämde först? Fördelen som jag ser det att ha olika implementationer av mina BDL är att jag enkelt kan byta tillbaka till en annan databas...
Nåja, hoppas jag inte skrämde bort er och jag läser gärna om hur ni löser det :)
285 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
