Jag behöver hjälp med att omvandla följande klass till en fungerande webservice, upptäckte ganska snabbt att properties inte kunde användas :( vilket gör det hela lite svårare.
public class addcustomer : System.Web.Services.WebService
{
private string c_firstname;
public string C_Firstname
{
set
{
c_firstname = value;
}
}
private string c_lastname;
public string C_Lastname
{
set
{
c_lastname = value;
}
}
private string c_address;
public string C_Address
{
set
{
c_address = value;
}
}
//.......osv, ett XX antal properties
public bool CreateUser()
{
//en massa som lägger in användaren i databasen och returnerar false eller true
}
}
Jag behöver hjälp med att omvandla följande klass till en fungerande webservice, upptäckte ganska snabbt att properties inte kunde användas vilket gör det hela lite svårare
Okej, du kan inte använda dig av properties!
Hur skall du då kunna få in dina parameters till dina variabler som du vill använda dig av i funktionen CreateUser. Då får man göra som man gör när man skickar värden till en vanlig funktion.
public int count(int tal1, int tal2){
int summa;
summa = tal1 + tal2;
return summa;
Känns det igen?
Om det är något annat som du har problem med, så får du skriva om din fråga, för enligt den så har du problem med att man inte kan använda sig av properties i webservices och lösningen på det är att man skickar med värdena som parameters in i CreateUser() funktionen. x(
[WebService(Namespace="CTest1.WebService",Name="Aleborgs AddUser", Description="Add a user to my database, please.")]
public class test : System.Web.Services.WebService
{
[WebMethod(Description="Inserts a new user. Returning True or False.")]
public bool CreateUser(string fName, string lName, string Address)
{
bool hmm = true; //Insert koden som retunerar True or False
if(hmm){
return true;
}
return false;
}
}
red// Märker ju inte att andra svarar medans jag skriver. :)
Gladh - > jag skrev "Jag behöver hjälp med att omvandla följande klass"
Jag löste det så här mha experts-exchange:
private string belongs_to;
[WebMethod()]
public void Belongs_To(string sValue)
{
belongs_to = sValue;
}
Ursäkta om jag frågar men hur kan det vara en lösning på problemet så där rakt av? Om nu inte belongs_to är Static eller du har nån annan metod för att bevara dess värde mellan anrop?
nico -> hur menar du?
Har inte hunnit testa den än, så jag vet inte om det funkar. Har inte arbetat med webservices innan!
Att göra så här skulle inte funka eftersom det är ca 90 strängar som kan sättas:
public bool CreateUser(string fName, string lName, string Address)
Om det är 90 strängar, så ta emot ett XMLdokument, med all data och sedan läser du ur datan från det XMLdokumentet i din funktion.
Du kan inte få med dig parameters på annat sätt än att definera dem i din funktion. Om du sedan gör 90 stycken, eller 1 som innehåller alla de 90 är bara 2 sätt att lösa samma problem på.
Själv tycker jag XML dokumentet är smidigare om det är så många.
Jag menar att Webservices funkar som Webforms; de instansieras på nytt vid varje HTTP-request. Att du anropar Belongs_To vid ett tillfälle innebär inte att belongs_to har kvar sitt värde när anropet till CreateUser senare kommer (inte ens på vad som förefaller vara samma objekt).
Vill du minnas status så får du använda sessions eller nån annan metod. Eller helt enkelt göra som Gladh/Dino föreslog: Skicka in hela klabbet i anropet till CreateUser (på ena eller andra sättet).
Visst är det enklare att skicka över en class eller ett dataset. Dessa två har dock sina nackdelar.
Classen:
Först måste du göra den Serializable. Vilket gör att din class kan skickas som en lång sträng. Det är dock inte speciellt svårt man sätter bara attributet [Serializable] på din class så är det löst. Det andra problemet är att både sändare och mottagare måste ha en definition på hur classen ser ut alltså måste din assembly finnas både på klient och server, vilket tar bort vitsen med webservices.
DataSet:
Dessa kan använda eftersom de är Serializable men kräver dock att det finns .NET framework på både klient och server vilket också tar bort iden med webservices lite grand. Sedan så skickas en ofantligt mängde extra data som du inte har behov av när du skickar ett dataset.
Så rent prestanda mässigt och för att göra din webservices så öppen som möjligt så bör du skicka in en XMLsträng och sedan använda denna när du skall skapa din användare.
Gladh -> Har du nått exempel på hur det skulle fungera?
Det som krävs när klienten pratar med webservicen är att ett användarnamn samt lösenord skickas med, verifieras sen i webservicen via databas.
Tanken är att den här webservicen ska användas i ett nätverk av datorer med IIS installerat.
Jag håller på med en kontrollpanel som behöver kunna prata med andra datorer i nätverket(ej domän), den delen som görs nu är för återförsäljare som ska kunna skapa en ny kund "on the fly" :D genom att skicka in sitt användarnamn och lösenord samt kundens alla uppgifter till en webservice ELLER liknande och få kontot skapat direkt. Det är inte heller säkert att ÅF's websida ligger på samma server som kontrollpanelen därför går det inte med en komponent bara.
Utöver webservices, vad finns det för alternativ för att få datorer att "prata" med varandra?
Visst är det enklare att skicka över en class eller ett dataset. Dessa två har dock sina nackdelar.
Classen:
Först måste du göra den Serializable. Vilket gör att din class kan skickas som en lång sträng. Det är dock inte speciellt svårt man sätter bara attributet [Serializable] på din class så är det löst. Det andra problemet är att både sändare och mottagare måste ha en definition på hur classen ser ut alltså måste din assembly finnas både på klient och server, vilket tar bort vitsen med webservices.
DataSet:
Dessa kan använda eftersom de är Serializable men kräver dock att det finns .NET framework på både klient och server vilket också tar bort iden med webservices lite grand. Sedan så skickas en ofantligt mängde extra data som du inte har behov av när du skickar ett dataset.
Så rent prestanda mässigt och för att göra din webservices så öppen som möjligt så bör du skicka in en XMLsträng och sedan använda denna när du skall skapa din användare.
- M
När du skickar ett dataset så skickar du i princip väl en XMLsträng, dock måste klienten veta hur denna skall läsas in, XSD filen..
Jag tycker att om man skickar en XMLsträng så tappar man lite av styrka med webservices. Klienten kan då inte "se" vad som kommer att skickas tillbaka utan måste läsa en XMlfil för att förstå detta. Jag tycker det är bättre att skicka en klass som är Serializable, som du sa. Då kan man i wsdlfilen läsa ut vad som kommer att komma tillbaka och slipper gissa. Då kan klienten se vad som kommer tillbaka genom att först läsa in wsdlfilen. (om man nu vill det).
Om man vill skicka en xmlfil så tycker jag att man kan skippa wskonceptet och bara använda sig av XMLRPC, vilket i princip är en ws utan lulllull så som wsdl och uddi.
Ja, man kan diskutera vilket som är bäst..
Mina synpunkter
Vet du inte vilka klienter som skall jobba mot webtjänsten, skicka klasser eller något liknande annars så skicka en XMLsträng.
När du skickar ett dataset så skickar du i princip väl en XMLsträng, dock måste klienten veta hur denna skall läsas in, XSD filen
Jopp DataSetet serializeras till en XMLsträng, det är dock inte bara datan som skickas utan en massa annat "skräp" som han inte har någon nytta av.
Om du dock endast skall använda det internet så hade jag istället använt mig av .NET Remoting som är snabbare än WebServices. Där kan du skicka klasser,DataSets eller XMLsträngar. I ditt fall så verkar det som att det endast är dina egna program som skall ha tillgång till denna funktion och du kan alltså då styra att varje client som kopplar upp sig har den klass som skall skickas med.
Så i ditt fall, hade jag använt mig av Remoting, med en class som jag hade skickat som Serializable.
ok, det låter intressant, men det är inte bara mina egna applikationer(mestadels iofs) utan även vissa andra ASP.NET applikationer, men dom kan man iofs instruera hur dom ska göra!
Var hittar man mer om remoting?
Funderar på att göra det ändå med dataset eller class, blir ju enklare att underhålla, gäller bara att ha en bra manual för dom som ska arbeta mot webservicen! Har just nu satt 90 parametrar i en funktion o det är inte snyggt :(
260 ms totalt · 3 externa anrop · v20260731065814-full.4bcf49fe
