fredrikMedlem sedan dec. 19991 072 inlägg Jag skulle behöva lite åsikter om hur affärs-logik ska behandlas...
Jag utvecklar ett system som ska köras på flera datorer på ett nätverk.
Gällande affärs-logiken, var tycker Ni att den ska läggas? På en server och sedan anropa med Remoting, eller på en server och använda Webservices? ...eller lokalt på varje klient?
Delar av systemet ska sedan köras via ASP.NET. Servern i detta fallet är den samma som Web-servern.
Helt klart är ju att underhållet och uppdatering av affärs-logik blir enklare om den läggs centralt....fast å andra sidan blir det ju en massa nätverks-trafik + att programmet antagligen blir långsammare. Dessutom är ju iaf Remoting ganska "meckigt" att få till bra (tycker jag det verkar som...).
System körs för övrigt i en 4/5-skiktad lösning där varje del är fristående i sig.
Vad tycker Ni? Tacksam för tips och idéer!
h0lgerMedlem sedan nov. 2002105 inlägg Du skriver att delar av systemet skall köras i ASP.NET. De andra delarna då? Är det ett stort system?
fredrikMedlem sedan dec. 19991 072 inlägg
Du skriver att delar av systemet skall köras i ASP.NET
Sorry..glömde säga det. Den största delen kommer att vara byggd som en Windows-applikation (winforms).
System kommer att bli ett stort system som tar hand om order-hantering, integration mot diverse "maskiner", integration mot ekonomi-system osv.
LaspMedlem sedan juli 200012 980 inlägg Helt klart bäst på sikt (när allt är testat) att regler ligger som sp.
Vad har du för db?
Även utan borde centralt vara bäst.
fredrikMedlem sedan dec. 19991 072 inlägg Kan väl ta och redogöra lite för hur mina skikt är tänkta...
1. Presentations-lager
Här körs klient-baserad kod, dvs winform-kontroller, valideringar och anrop till affärs-logik. Även ASP.NET klienten ligger här.
2. "Fasad-lager
Då Winforms och ASP.NET ofta behöver bearbeta data från affärs-lagret olika implementeras här olika metoder för att returnera data till presentations-lagret på rätt sätt.
3. Affärs-lager
Här läggs all logik, bearbetning av data, parametrar och logik för DB-anrop m.m. Log-hantering, Exception-hantering osv.
4. Data-kommunikations-lager
Här "Wrappas" ADO.NET in så att alla anrop från Affärs-lagret går via detta lager istället för att gå via ADO.NET. Detta för att underlätta Exception-hantering och underlätta underhåll vid nya .NET-providers eller ny logik för ADO.NET.
5. Data-lager
SQL-server 2000 där alla frågor körs som Stored Procedures.
nikoMedlem sedan juni 20022 599 inlägg Huruvida man ska använda tunna eller "tjocka" klienter beror väl i hög grad på hur många klienter det finns? Har man 5 st klienter inom gångavstånd så behöver man kanske inte vara så rädd att baka in affärslogik/finesser i dessa (om det finns ett syfte). Det är ju inte så jobbigt att hålla ett litet antal klienter uppdaterade och buggfria.
Har man nåt hundratal klienter, och dessutom på olika plattformar, så ska man nog försöka vara så tunn (helst anorektisk) som möjligt.
fredrikMedlem sedan dec. 19991 072 inlägg Antalet klienter kommer med största sannolikhet inte överstiga 20 st, alla kommer dessutom sitta i samma byggnad (Samma LAN iaf).
renholmMedlem sedan apr. 20012 266 inlägg Är det inte rätt smidigt att skippa Winforms och köra allt via browsern? om det är möjligt dvs. Apropå det här med winforms klienter så behöver det inte bli jobbigt att underhålla och byta version på dem, bara att köra dem via nätverket?
Sedan om vi återgår till vart man bör placera affärlogiken så tycker jag det borde göras centralt och att klienter får data genom antingen WebServicer, Remoting eller egen tcp lösning.
Du skriver om "en massa nätverkstrafik", för t.ex orderbehandling tror jag inte nätverkstrafiken blir något större problem.
h0lgerMedlem sedan nov. 2002105 inlägg Om man tycker att .NET Remoting är krångligt kan Web Services vara intressant. Men ser man till prestanda så är Remoting snabbare i vissa konfigurationer. Dock vet jag inte riktigt hur mycket det skiljer i utvecklingstid för de olika alternativen.
Kolla denna artikeln på MSDN
http://msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch14.asp?frame=true
Web Services och Remoting har inte riktigt samma mål och används lite olika. Se Remoting som ett sätt att kommunicera mellan (dina egna) olika appdomains (exempelvis mellan två applikationer) och web services som ett sätt att prata med andra applikationer (exempelvis när du vill lämna ut information till andra).
I de flesta fall tror jag Asp.Net är ett bättre val än remoting, framförallt för att implementationen blir enklare. Krävs högre prestanda och man kan släppa kravet på att kommunicera med andra typer av plattformar är Remoting ett alternativ där man kan använda ett effektivare binärt protokoll direkt på TCP.
http://msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch16.asp
nikoMedlem sedan juni 20022 599 inlägg
renholm skrev:
Apropå det här med winforms klienter så behöver det inte bli jobbigt att underhålla och byta version på dem, bara att köra dem via nätverket?
Ja, kanske i teorin .. om alla klienter vore identiska. Men i praktiken brukar klienter skilja sig åt lite grann vad gäller: operativversion, service packs, installerade komponenter, rättigheter, mappningar osv .. Detta brukar ha en tendens till att ställa till det mer än man först tror.
fredrikMedlem sedan dec. 19991 072 inlägg
Är det inte rätt smidigt att skippa Winforms och köra allt via browsern?
Tyvärr är det inte möjligt, då en massa windows-specifika funktioner används för drag-n-drop, tree-views osv. Jag vet att det finns vissa kontroller för asp.net med....men det passar inte riktigt.
Systemet jobbar mot affärs-logiken hela tiden som i sin tur jobbar mot data-källan, därav att det borde bli nätverks trafik om affärs-logiken läggs på en server.
Ja, antingen får det nog bli webservices eller att affärslogiken får hänga med till klienten.
(Vissa delar kommer ändå att köras som Webservices för annan kommunikation).
Tack för alla inlägg!
