Har en liten fråga angående design av gränssnittet mellan klienten och "businessrules".
Vi håller på och bygger en applikation i VS.NET 2003 och använder oss av C#. Vi har valt att kommunicera med webservices mellan klienten och servern.

Vad är bäst att göra, använda sig av en webservice och lägga in alla funktioner i den eller använda sig av massa webservices med mindre antal funktioner i varje?

Finns det någon prestandaförsämring med många webservices, förutom att det är jobbigt att lägga till alla i projektet. :-)

Eller är det så att man försöker ha minimalt antal webservices och att varje webservice istället har flera metoder.

Hoppas ni förstår vad jag frågar efter, har nämligen inte hittat mycket om just detta trots att vi har Books24x7 på jobbet. ;-)

Om jag förstått din fråga rätt så är Webservices ett långsammare alternativ att kommunicera med och att bygga en hel applikation runt detta låter som överkurs. Webservices används ju mest för det "delade" syftet där men har behov av att nå informationen från flera oberoende källor. Du kanske skall titta på "fasader/fascade" där du istället kan välja att gå mot webservice kontra applikation beroende på vem som kallar på datat.

Oki, det vi håller på och bygger är en distribuerad applikation där man skall kunna sitta med klienten utanför det befintliga nätverket, alltså över internet.

Är det då remoting man måste använda sig av?

Vi har använt oss av en template från VS för distribuerad applikation.

Jimmy,

Njäae.. det beror lite på vad ni har för krav på er. Typ prestanda, sökerhet, brandväggar, transaktioner mm.

Här har du bra läsning (han snackar om WS med) http://www.thinktecture.com/Resources/RemotingFAQ/RemotingUseCases.html

Säkerhet är ju nummer ett. Sen kommer ju prestanda, men inte att det kräver realtidstrafik. Det är ju ett affärssystem så de tunga jobben kommer ju att göras på serverdelen. Och då tyckte vi efter kollat en del att webservices verkar smidigt eftersom man får mycket och kommunikationen och säkerhet via IIS'en "gratis".

Jimmy,

WebServices med hjälp av Web Service Enhancements 2.0 är en väldigt bra plattform, som erbjuder många finesser så som säkerhet. Förövrigt har jag försökt minimera antalet webservices, men att skapa logiska grupper av dem.

Säg att du skapar en webservice för Kundhantering och en för Orderhantering. Låter ok va? Visst är det så, men behövs det? Det beror på dina behov. Kommer det finnas klienter (mjukvara) som bara arbetar mot kundhatering? Andra som enbart arbetar med orderhantering.. kanske de som arbetar med båda? Säg att ingen av dem kommer användas seperat, utan bara tillsammans.. då får man analysera djupare om man kanske behöver tåv seperata services, eller om man vill köra det som en. Kanske vill man lägga dem på olika servrar för orderhanteringen kommer belastas 10 ggr hårdare än kundhateringen mm.. Väldigt svårt att ge konkreta förslag utan att veta hur er kravspec är formulerad =)

Web Services Enhancements (WSE) 2.0 SP1 for Microsoft .NET
http://www.microsoft.com/downloads/details.aspx?FamilyId=FC5F06C5-821F-41D3-A4FE-6C7B56423841&displaylang=en

Tack för länkarna. :-)

Vi har använt oss av detta verktyg, http://www.gavinjoyce.com/nTierGen/?_sm=Overview för att generera lagerna som vi sedan bygger på med specifika funktioner.
Vad den också genererar är webservices för alla tabeller och vyer man skapar, och det medför att man isåfall får lägga till en webservice per tabell plus vyer. Jag tycker inte att det känns som en bra design.

Tacksam för synpunkter. :-)

Jimmy,

Oj, min spontana reaktion är "blää! fy tusan". Det kommer juh bli på tok för många webservice att underhålla. Vad du bör göra är att åtminstånde gruppera dem i logiska grupper, som jag tidigare nämnde - detta är vad pelle var inne på innan med att skapa facad-lager.

En facad är juh vad det låter som - den döljer det som finns bakom och presenterar det i en alternativ form. Så vad du gör är att skapa en webservice som exponerar de metoder som du skulle behöva, tex om du hade gjort för orderhantering så kanske du hade behövt GetOrderById, AddNewOrder(Orderitem) etc.. när du har definerat denna facad (blir juh en facad på implementationssidan och ett gränssnitt (programmerings, inte användar)) på konsumsionssidan) så kan du börja klia dig i huvudet och luska ut hur du skall få till en önskade funktioneliteten i facaden med hjälp av det underliggande lagret.

Hoppas du hajjar annars försöker jag skriva om det igen - sitter mitt upp i en sak så jag skriver direkt ur huvudet utan att tänka igenom ;)

<b>PS:</b> Menade inget illa om Gavins verktyg med mitt "blää! fy tusan", har sett gavin utveckla det verktyget sen första början och det har vuxit till sig ber, men en WS/tabell&vy är påtok fel, inte minst med avseende på att underhålla systemet.

Tacksam för att du tar dig tid att svara.
Förstår vad du menar. ;-)

Vi har väl upptäckt att det verktyget kanske inte alltid genererar den bästa lösning för stora projekt. :-/
Men vi tycker att vi sparar mycket tid på att slippa bygga själva DataAccesslagret själva och kan koncentrera oss på de mer väsentliga bitarna.

Anledningen till tråden från början var att jag inte gillade lösningen med många WS utan tycker också att man isåfall exponerar en WS med flera metoder i istället.

Det med fasadlösningen låter intressant då vi har ett projekt som heter BusinessFacadeProjects men vi vet inte riktigt hur vi skall använda det. Har läst MS dokumentation och vet teoretiskt vad det skall användas för men inte riktigt hur man skall implementera det hela. Antar att WinUIprojektet skall kommunicera med BusinessFacade men hur?

Skall man då använda sig av Remoting?
Och sedan exponera vissa metoder vi WS som man kan tänkas använda för externa applikationer?