Jag har har en webservice som tar emot och returnerar klasser (sparar uppdaterar osv). Vissa av dessa webservices jag har tar emot och returnerar GenericCollections, problemet är att webservicen hanterar detta som vanliga collections, om min webservice ser ut så här:
public GenericCollection<User> GetAll()
{
....
}
så ser jag i klienten att den returnerar User[], vilket tyvärr inte går att konvertera rakt upp och ner till en GenericCollection med typ (GenericCollection<webService.User>)webService.GetAll()
änne större problem är att vissa klasser innehåller properties som är GenericCollections.
Någon som vet hur man enkelt löser detta? Om det ens går?
Nu orkar jag inte läsa erkas fina länkar som säkert säger samma sak som jag (eller inte, och då har de FEL!!!).
Remotin i .NET 1.1 var slöt om man använde sig av DataSet (gud nåde den som gör såna dumheter) och skickade dessa mellan sig, och det berodde helt enkelt på att .NET Remoting så fall valde XMLSerializering av dessa även om man valt Binary-formattet.
i .NET 2.0 skall detta vara löst och man serializerar nu sina DataSet som binary istället, vilket ökat prestandan lite. I vilket fall som helst så skall man inte använda sig av dataset utan skriva sina egna entiteter och skicka dessa som databärare och då får du en bra mycket bättre prestanda än med en webservices.
För att göra det ännu enklar skall du inte skriva varken webservices eller remoting kod, utan använda dig av .NET 3.0's Windows Communication Foundation och där sedan konfigurerar din kod så att du kan välja om du vill ha din endpoint som en webservice eller remoting, eller varför inte MSMQ. Så skall du skriva program som skall kommunicerar med varandra så är det WCF som gäller och inget annat....
När jag nu sagt det så kan jag ju säga att jag inte lever som jag lär ;)
- M
Det är ju inte mycket info men jag testade exemplet och fann det väldigt intressant.
Var kan man få mer info om detta och .NET 3.0's Windows Communication Foundation, alla som ska använda programmet kör Vista samt att .NET 3.0 är släppt till Windows 2003 Server så vi har inte det problemet någonstans.
Lite OT men: vi kör .NET 3.0 och WCF i vårt projekt, har gjort länge (stort projekt...) och har inte stött på några problem fast att vi har blandade miljöer :). Det var dock ett strul med installationen om man installerade allt i fel ordning, då kunde man råka ut för att få rensa det mesta och börja om...
Som jag förstått det så stödjs .NET 3.0 fullt ut av XP men man måste givetviss ladda ner Framework 3.0 men det är ju ingen skillnad jämfört med de andra versionerna.
WCF information kan du hitta på nätet hur mycket du vill. Vill du ha en bra grund att stå på så kan jag faktiskt rekomender Johan Lindfors blogg samt den svenska MSDN siten som har någon film om WCF, där man bygger en services från grunden...
De klasser som du gjort tidigare och skickat igenom dina webservices blir dina entiteter, de fungerar helt enkelt så att all logik skalas bort och det endast är data som ligger som publika properties som kommer att skicas över webservicen. Detta har sina för och nackdelar med denna approch, och den stora fördelen blir att du får mindre klasser och mindre kod att hålla reda på eftersom du bakar ihop dina objektklasser med dina dataklasser. De flesta är emot en sådan lösning, men den är väldigt praktisk ur sin synpunkt. Tyvärr så för den med sig en del nackdelar också eftersom logiken inte förs med över webservicen, och logik som du tar förgiven på din sida måste kodas ytterligare en gång på andra sidan (om man inte råkar ha tillgång till samma assembly). Därför så rekomenderar man istället att man endast skriver databärare och sedan så skickar man dessa till services för att opererar på dem.
Så för att vara riktigt petig så kan man säga så här: om du har en entitet som håller information om en person, typ födelsdata, och du vill ha tag på åldern på denna person, så skall du inte lägga denna logik i din entitet utan koda in det i ditt program, och om det är så att det är många olika program som vill ha just denna funktion, så skall du alltså bygga en services, som tar ett personentitet och returnerar tillbaka ålder på personen (klart överdrivet, men du förstår säkert).
Det de verkar göra i artiklen är att de skapar entiterna ifrån databasen i runtime miljö, vilket är riktigt häftigt, men ändå lite felaktigt, eftersom en entitet inte skall spegla databasens struktur utan din verksamhetsstruktur, det betyder att din entitet kanske skall hämta information från flera tabeller i en databas, eller kanske flera databaser för att på ett korrekt sätt spegla din objektmodell som man byggt upp för företaget. Oftas är det dock så att man många gånger kan göra nästan en 1:1 mappning mellan databasen och entiteterna, men det behöver inte vara så...
Då tror jag att jag är rätt "home safe", jag brukar skapa ett antal projekt i mina lösningar:
1 DAL
1 Class, innehåller alla klasser
1 BOL, sparar/hämtar från databasen samt diverse enklare funktioner
1 Work, gör lite hårdare arbete, skapar mappar/filer, samkör med andra system osv. Den typ av funktioner som kräver externa komponenter eller måste interagera med andra system.
1 Client
1 Server
Det mesta sker på servern men enklare funktioner kan läggas på klienten.
Håller på att bygga om en del av våra interna system på jobbet och då verkar det som ett ypperligt tillfälle att byta ut webservices mot nått bättre :D
136 ms totalt · 3 externa anrop · v20260731065814-full.4bcf49fe
