Hej!

Jag skall hämta data från en tabell och sedan skicka den till en webservice som lägger till uppgifterna i en likadan tabell. Att använda ett DataSet fungerar, men eftersom det bara är data från en tabell så känns det lite onödigt att skicka ett helt dataset.
Problemet är att jag inte vet vilket sätt jag skall göra det på.
Några förslag?

hur många tabeller har databasen?
hur stora är dom?
hur mycket data kan som mest komma att uppdateras vid en tidpunkt?
hur ofta kan uppdateringar göras som mest vid "rusningstrafik"?

när det gäller databaser och uppdateringar, så spelar ovan ställda frågor
en stor roll för att maximera prestandan.

Om det rör sig om frekventa uppdateringar med små mängder ändrad
data kan det vara läge att skicka en datatable som är en delmängd
av datasetet (med aktuell ändrad data).

det är också intressant att veta om concurrency finns med i bilden?
kommer flera användare parallellt göra ändringar i databasen?
(WebServicen är ju publik!)

mvh. Gottfrid

Det är i första hand 5 tabeller som påverkas.
Data från försäljningstabellen är den som kommer att påverkas mest frekvent (inom 5 minuter) och där skall man bara lägga till data. (max 30 poster per gång)
De andra tabellerna kommer kanske att påverkas var timme och där kommer man att lägga till poster, uppdatera poster och ta bort poster.

Tanken är att tillsammans med datat skicka med ett unikt id som talar om vilken butik det gäller och därmed också vilken databas som skall uppdateras.

5 tabeller och 30 poster var 5:e minut är ju inga mängder så jag ser inga bekymmer där. Se däremot till att du genererar någon krypterad nyckel till alla de som får posta som skickas med. Är det känslig data se även till att köra över SSL så det blir krypterat.

Som jag ser det är detta inga problem alls, vare sig med prestanda eller säkerhet om du som sagt har en unik nyckel som genereras och ges till varje behörig klient.

Tror inte heller det blir problem med mängden data.

Jag har bara fått det att fungera med DataSet, inte DataTable
Sedan har jag loopat igenom tabellen och lagt in varje post för sig. Tänkte att det kanske fanns ett "smartare" sätt att göra det på.
Det känns lite mastigt att använda sig av ett DataSet när det bara är en tabell jag uppdaterar eller hämtar information från.

tänkte bara förtydliga en sak,
ett dataset kan innehålla flera tabeller, en tabell, delar av en tabell, delar av flera tabeller (typlika)
Ett sätt som kanske vore nåt för dig är att skicka ändringarna i ett mini-dataset och sen merge:a
in det med databasen i WebMethoden (webservicen).

Vad menar du med "mini-dataset"

Lars menar att skillnaderna är att dataset är ett komplext objekt. I ett dataset kan hur många datatables som helst finnas (dvs det som får plats i minnet). Du kan istället använda en datareader som är mer slimmad och har inte så mycket overhead. Sen är det ju xml som skickas genom soap om du kör via proxy så det blir inte så stora mängder data.

Jag föreslår att du testar, får du prestandaproblem så kanske det är dags att designa om. Men återigen. Det är så lite data du pratar om så det skall inte vara några problem att köra dataset för tillfället. Optimering kan du ägna dig åt om det börjar bli trögt.

Du behöver skicka som Dataset i en Webservice eftersom Dataset är Seialiserbart, det är inte DataTable. Du har därför inget val. Jo du kan bygga egna klasser som är serialiserbara men det vinner du inte mycket på. Kör Dataset. Det är OK. Jag kan aldrig tänka mig att du får prestandaproblem bara för att du väljer Dataset framför någon mer "slimmad" datastruktur.

"Jo du kan bygga egna klasser som är serialiserbara men det vinner du inte mycket på. Kör Dataset"

Det är ju en sanning med modifikation, dels så är egna klasser betydlgit lättare än ett DataSet vilket gör att mindre data skickas. Men framför allt så har man uppnått det som är meningen med WS, att de kan anropas från vilket system som helst, försök kalla på en WS som tar emot ett DataSet från en Javaklient och se hur bra det går!

Att använda sig av .NET specika typer i WS är styggelse och något som fungerar bra i Microsofts klicka-gissa-spring exempel, i den verkliga världen fungerar det dock inte så bra.

- M

Har en fråga som bygger på det.. Om jag vill skicka in ett xml-dokument till en web-metod. Är det då sträng som gäller för att göra det "klient-plattforms-oberoende"? Eller går det lika bra (bättre?) med en filestream?

Mvh
Peter

Sträng helt klart, en filestream är ju (om det ens går) taget direkt ifrån .net framework

"Det är ju en sanning med modifikation, dels så är egna klasser betydlgit lättare än ett DataSet vilket gör att mindre data skickas. "


Det är ingen stor skillnad alls.
Eller, exakt hur mycket lättare är det menar du? och vad är det som väger mindre?


" Men framför allt så har man uppnått det som är meningen med WS, att de kan anropas från vilket system som helst, försök kalla på en WS som tar emot ett DataSet från en Javaklient och se hur bra det går! "


Det klart det går! Varför skulle det inte gå? Det som skickas är well-formed XML. Detta är lätt för en Javakodare att hantera. Jag har ett system som skickar DotNet Dataset till en IBM OS/390 stordator - det fungerar utmärkt.


" Att använda sig av .NET specika typer i WS är styggelse och något som fungerar bra i Microsofts klicka-gissa-spring exempel, i den verkliga världen fungerar det dock inte så bra."

Ja, kan man hitta en mer plattformsoberoende standardiserad datatyp samt har behov av plattformsoberoende, så är ju detta att föredra. I så fall kan man också mkt enkelt konvertera sin Dataset-XML till något mer önskvärt (t.ex vad?) med XSLT. (jag förstår inte hur du ska strukturera tabelldata i en form som väsentligt skiljer sig från Dataset-XML men upplys mig gärna om det.. ;))

Det är väl ändå smartare att användat ett Dataset än någon obskyr hierarkisk datatyp, som man hittar på själv. Chansen finns ju att Javautvecklare har pratat med en DotNet-WS förr och har byggt nåt som kan läsa in Datasets. Det kan inte vara så svårt eftersom det är ju väldigt logisk XML-struktur som skickas.

Skicka absolut inte XML som en sträng (Datatype String)
Vad som händer då är att hela XML-meddelandet måste escape:as så du får
&ltblabla&gt
&ltblabla&gt
&ltblabla&gt
osv. Detta vill man inte ha.

Förutsatt att du bygger dit proj som en ASP.NET Webservice alltså.

Skicka som typ XmlElement i stället. Då får du ren XML och du får det lätthanterligt i DotNet.

Ok. Är XmlElement en typ som andra förstår, t.ex. Java-programmerare eller system på stordatorer?

Eller, kanske ska ställa om frågan. Hur skickar jag lättast in xml-data till en funktion?

De andra svaren här i tråden tyder på att det kanske är dataset ändå..?

Mvh
Peter

Ja, XmlElement blir helt enkelt XML när det serialiseras till XML av ASP.NET Webservices.

Men har du ett Dataset och dina klienter är DotNet så är det ju lika bra att använda det..

Skapar en ny tråd. :)

/Peter

Hej!

Undrar bara om man kan kryptera endast en del av informationen, t.ex. företagsId.
Själva datat behövs inte krypteras utan endast det id som skiljer användarna åt.

Var kan man hitta isf exempel på detta?

"Det är ingen stor skillnad alls.
Eller, exakt hur mycket lättare är det menar du? och vad är det som väger mindre? "

Har en tabel som heter color i min databas, en metod returneras som dataset och den andra returneras som en array av objektet Color.

Detta är det som skickas med DataSet som retur typ:

  <?xml version="1.0" encoding="utf-8" ?> 
- <DataSet xmlns="http://tempuri.org/">
- <xs:schema id="NewDataSet" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
- <xs:element name="NewDataSet" msdata:IsDataSet="true" msdata:UseCurrentLocale="true">
- <xs:complexType>
- <xs:choice minOccurs="0" maxOccurs="unbounded">
- <xs:element name="Table">
- <xs:complexType>
- <xs:sequence>
  <xs:element name="Identifier" type="xs:int" minOccurs="0" /> 
  <xs:element name="Name" type="xs:string" minOccurs="0" /> 
  </xs:sequence>
  </xs:complexType>
  </xs:element>
  </xs:choice>
  </xs:complexType>
  </xs:element>
  </xs:schema>
- <diffgr:diffgram xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1">
- <NewDataSet xmlns="">
- <Table diffgr:id="Table1" msdata:rowOrder="0">
  <Identifier>1</Identifier> 
  <Name>Black Beige</Name> 
  </Table>
- <Table diffgr:id="Table2" msdata:rowOrder="1">
  <Identifier>2</Identifier> 
  <Name>Beige Green</Name> 
  </Table>
- <Table diffgr:id="Table3" msdata:rowOrder="2">
  <Identifier>3</Identifier> 
  <Name>Dark Brown</Name> 
  </Table>
- <Table diffgr:id="Table4" msdata:rowOrder="3">
  <Identifier>4</Identifier> 
  <Name>Beige</Name> 
  </Table>
- <Table diffgr:id="Table5" msdata:rowOrder="4">
  <Identifier>5</Identifier> 
  <Name>red</Name> 
  </Table>
- <Table diffgr:id="Table6" msdata:rowOrder="5">
  <Identifier>6</Identifier> 
  <Name>Blue</Name> 
  </Table>
- <Table diffgr:id="Table7" msdata:rowOrder="6">
  <Identifier>7</Identifier> 
  <Name>Röd</Name> 
  </Table>
  </NewDataSet>
  </diffgr:diffgram>
  </DataSet>

Detta blir resultatet med en array av objekt.

  <?xml version="1.0" encoding="utf-8" ?> 
- <ArrayOfColor xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/">
- <Color>
  <Identifier>1</Identifier> 
  <Name>Black Beige</Name> 
  </Color>
- <Color>
  <Identifier>2</Identifier> 
  <Name>Beige Green</Name> 
  </Color>
- <Color>
  <Identifier>3</Identifier> 
  <Name>Dark Brown</Name> 
  </Color>
- <Color>
  <Identifier>4</Identifier> 
  <Name>Beige</Name> 
  </Color>
- <Color>
  <Identifier>5</Identifier> 
  <Name>red</Name> 
  </Color>
- <Color>
  <Identifier>6</Identifier> 
  <Name>Blue</Name> 
  </Color>
- <Color>
  <Identifier>7</Identifier> 
  <Name>Röd</Name> 
  </Color>
  </ArrayOfColor>

betydligt mindre mängd data som skickas, visserligen så blir inte skillnaden så stor när mer data skall skickas, utan då är det mer den extra information som följer med varje post som börjar ta plats...


"Det klart det går! Varför skulle det inte gå? Det som skickas är well-formed XML. Detta är lätt för en Javakodare att hantera. Jag har ett system som skickar DotNet Dataset till en IBM OS/390 stordator - det fungerar utmärkt."

Klart det fungerar, men det är inget DataSet objekt som du får ut på andra sidan... Alltså din webservice kommer inte att fungerar likadant för alla plattformar, vilket knappast är så bra. Men som du säger så är det en XML-struktur som skickas och tillsammans med den en wsdl/xsd som berättar hur typerna skall se ut. Så givetviss så skall en Java-klient kunna bygga ett objekt som heter DataSet, men det kommer inte fungerar som DataSet i .NET.

"Det är väl ändå smartare att användat ett Dataset än någon obskyr hierarkisk datatyp, som man hittar på själv. Chansen finns ju att Javautvecklare har pratat med en DotNet-WS förr och har byggt nåt som kan läsa in Datasets. Det kan inte vara så svårt eftersom det är ju väldigt logisk XML-struktur som skickas. "

Det är din åsikt, min åsikt och erfarenhet sig mig något annat, speciellt om man använder sig av "contract-first".

- M

"Har en tabel som heter color i min databas, en metod returneras som dataset och den andra returneras som en array av objektet Color.
betydligt mindre mängd data som skickas, visserligen så blir inte skillnaden så stor när mer data skall skickas, utan då är det mer den extra information som följer med varje post som börjar ta plats..."

Men du kan ju styra serialiseringen så att du slipper skicka med schemat och du måste inte heller välja diffgram.

"Så givetviss så skall en Java-klient kunna bygga ett objekt som heter DataSet, men det kommer inte fungerar som DataSet i .NET."

Det finns väl inget som hindrar dem att skriva ett program som tar in XML-datat och hanterar det med snarlik funktionalitet.

" "Har en tabel som heter color i min databas, en metod returneras som dataset och den andra returneras som en array av objektet Color.
betydligt mindre mängd data som skickas, visserligen så blir inte skillnaden så stor när mer data skall skickas, utan då är det mer den extra information som följer med varje post som börjar ta plats..."

Men du kan ju styra serialiseringen så att du slipper skicka med schemat och du måste inte heller välja diffgram.

"Så givetviss så skall en Java-klient kunna bygga ett objekt som heter DataSet, men det kommer inte fungerar som DataSet i .NET."

Det finns väl inget som hindrar dem att skriva ett program som tar in XML-datat och hanterar det med snarlik funktionalitet.
"

Japp allt är sant, och jag kan även bygga ett helt eget ip-protokoll för att kommunicera mellan de olika maskinerna.
Fördelen med webservice är att de är någolunda standadiserade vilket gör att det är enkelt och snabbt sätt att gå igång en kommunikation mellan olika plattformar. Om man helt plötsligt skall börja bygga en massa extra funktionallitet bara för att man skall få skicka sina dataset så har man liksom missat poängen och man kan då istället börja skriva egna TCP sockets klasser, eftersom det är betydligt bättre prestanda på dem och glömmaa webservices helt och hållet, eftersom iden redan har gått förlorad.

- M