Microsoft Sql Server 2005+ ? Dan kun je gewoon een CLR sp/trigger maken. Zie bv. http://davidhayden.com/blog/dave/archive/2006/04/25/2924.aspxquote:Op zaterdag 31 juli 2010 09:06 schreef Tarabass het volgende:
Ik wil graag vanaf een sql-server (via sp of trigger?) een webservice aanroepen. De situatie is nu zo dat de webservice elke zoveel seconde praat tegen de database wat een vorm van overkill is. Ik wil op het moment dat er een record aan een bepaalde tabel wordt toegevoegd dat de webservice hiernaar luistert. Wie weet een leuke interessante tutorial om dit te bewerkstelligen?
Thx voor de link, ik heb hem gelezen en ga het eens proberen.quote:Op zaterdag 31 juli 2010 09:39 schreef OEM het volgende:
[..]
Microsoft Sql Server 2005+ ? Dan kun je gewoon een CLR sp/trigger maken. Zie bv. http://davidhayden.com/blog/dave/archive/2006/04/25/2924.aspx
(ik zou zelf het aanroepen van de webservice niet in de database doen, maar ergens in je proceslogica cq businesslogica. Afhankelijk van wat die webservice doet lijkt me zelfs het pollingmechanisme me nog beter)
Je ziet heel vaak dat er processen geimplementeerd zijn op de manier van:quote:Op zaterdag 31 juli 2010 10:18 schreef Tarabass het volgende:
[..]
Thx voor de link, ik heb hem gelezen en ga het eens proberen.
Vanuit de database lijkt me centraler. Anders moet ik door de gehele applicatie de service aanroepen bij het updaten/inserten/deleten van een record uit de tabel. De tabel is een soort logtabel waarin gebeurtenissen vastgelegd worden. De webservice moet aan de hand van een nieuw record (gebeurtenis) een xml teruggeven die ik weer uitlees. Bij het aanroepen van de webservice van BL kan ik net zo goed de webservice ertussen uit laten toch? Of kijk je er anders tegenaan?
De bedoeling is overigens dat de ene gebruiker te zien krijgt wat een andere gebruiker gedaan heeft. Puur hypothetisch; gebruiker 1 maakt een gebruiker aan in het systeem. Gebruiker 2 krijgt visueel te zien dat gebruiker 1 een gebruiker heeft aangemaakt (met uitgebreide info natuurlijk ). Op deze manier leek het me handig dat ik én log én die tabel direct gebruik voor auditional info..
De (network)credentials die je toekent aan die XmlResolver object wordt gebruikt om aan te kloppen bij de server aan de andere kant voordat er ook maar iets inhoudelijks gebeurt met je bericht. Bij private en public albums praat je met een service die alles doorlaten bij het aankloppen. Het meegeven van networkcredentials is dus nutteloos. Daarna wordt er gekeken in het bericht wat je wil doen:quote:Op vrijdag 30 juli 2010 23:39 schreef Cryothic het volgende:
Ja, dat zou nog kunnen.
Maar ik kom dan weer nergens tegen hoe ik de verkregen AuthKey mee geef in m'n xml request.
Al die voorbeeld code die ik tegen kom, maakt niet gebruik van de nieuwe XmlReaders
Misschien is het ook gewoon te laat hiervoor
Nog even als toeveoging op mijn vorige reactie:quote:Op vrijdag 30 juli 2010 00:24 schreef Cryothic het volgende:
Ik probeer m'n albums op te halen, maar krijg een 403 forbidden.
Ah, dat maakt het wel duidelijker, en logischer idd.quote:Op zaterdag 31 juli 2010 11:02 schreef OEM het volgende:
[..]
De (network)credentials die je toekent aan die XmlResolver object wordt gebruikt om aan te kloppen bij de server aan de andere kant voordat er ook maar iets inhoudelijks gebeurt met je bericht. Bij private en public albums praat je met een service die alles doorlaten bij het aankloppen. Het meegeven van networkcredentials is dus nutteloos. Daarna wordt er gekeken in het bericht wat je wil doen:
Public album? Geen probleem.
Private album? dan moet er ook een authentication token in je bericht zitten.
Dus wat betreft de XmlResolver classes:
public album: everything goes, dus de XmlResolver-classes werken gewoon
private album: je zal eerst een sessie moeten starten via ClientLogin, en daarna de token die je krijgt elke keer meegeven. Dat is allemaal niet standaard, dus werken de XmlResolver classes niet meer. Dus je zal toch echt zelf twee webrequests moeten implementeren (zoald eerder iemand al gemeld heeft). Die kun je daarna evt ook gebruiken in het public geval.
Klinkt alsof System.Collection.Generic.Dictionary nodig hebt.quote:Op maandag 2 augustus 2010 10:14 schreef Cryothic het volgende:
Zo, even een soort van Best Practice vraag.
Het verhaal:
Ik haal bij picasa een lijst op van m'n fotoalbums.
Vervolgens sla ik die op in een tabel in m'n database, met daarbij een flag of ie wel of niet getoond mag worden op m'n website.
Nou wil ik, dat als ik later opnieuw ga syncen, uit m'n database een lijst van alle albums (zodat ik wijzigingen kan checken, en kan kijken of ze wel of niet gepubliceerd staan).
Wat is nou het beste objec
Dictionaryt om deze lijst in op te slaan?
Ik zit zelf te denken aan een GenericList.
Hierin kan ik een verzameling "album-objecten" in opslaan, en deze is tevens m.b.v. FindIndex te doorzoeken. (als ik m'n lijst uit de picasa-xml uitlees, kan ik dan snel op ID achterhalen in m'n eigen lijst of een album bijvoorbeeld gepubliceerd is).
Of is hier een beter object voor?
Dat klopt, en dat is niet erg: je albums worden geindexeerd op album_id (door middel van een hashtable), zodat het opzoeken van een album bij een bepaald id niet tot gevolg heeft dat de hele lijst van albums doorlopen hoeft te worden - de dictionary weet meteen waar hij heen moet springen.quote:Op maandag 2 augustus 2010 11:53 schreef Cryothic het volgende:
Maar voor een dictionary moet ik het dan opslaan als:
Generic.Dictionary[ album_id, album_object]
terwijl het ID ook al in het object zelf zit.
1 2 | Dictionary<int, Album> dict = albums.ToDictionary(elt => elt.ID); |
In theorie wel in ieder geval. In de praktijk ligt het kantelpunt geloof ik op 10 elementen (bij meer dan 10 elementen is een dictionary sneller, bij minder zou een gelinkte lijst sneller moeten zijn).quote:Al is dit met uitlezen misschien wel weer sneller dan de find-optie van een list.
LINQ vind ik handig voor op een klein website`je, effe snel wat data op te halen uit een database en hier met behulp van IntelliSense gemakkelijk iets mee doen. Voor de wat grotere projecten maak ik toch sowieso zelf mijn eigen object classes en data layer. Overigens ben ik een voorstander van data die al zo gebruiksklaar mogelijk uit een database komt, in plaats van eerst een rommelige, ongesorteerde resultset op te halen en hier pas in de applicatie van alles mee doen.quote:Op dinsdag 3 augustus 2010 09:04 schreef Cryothic het volgende:
Tja, bij het synchronizeren kom ik langs alle albums, dat zijn er (in m'n eerste account) 88.
Dus dan gaat een dictionary dat wel winnen ja.
Of ik Linq ga gebruiken weet ik nog niet.
Daar ben ik niet in thuis. 1x gebruikt voor een Twitter-feed op m'n site.
Op m'n werk wordt het iig ontmoedigd, maar het is me niet helemaal duidelijk waarom. Zal wel persoonlijke smaak zijn.
Dank je wel in ieder geval
Wat hem tegenhoudt zijn waarschijnlijk die andere developers die fijn vanuit de presentatielaag in de datalaag zitten te frutten.quote:Op dinsdag 31 augustus 2010 11:00 schreef NikkelCobalt het volgende:
Wat houdt je tegen een repository te schrijven?
Dat inderdaad. Veel 'gelaagdheid' komt er niet bij kijken in dit geval.quote:Op dinsdag 31 augustus 2010 11:04 schreef Catbert het volgende:
[..]
Wat hem tegenhoudt zijn waarschijnlijk die andere developers die fijn vanuit de presentatielaag in de datalaag zitten te frutten.
Jij hebt het wel over het weakly-typed LINQ taaltje. Je hebt ook nog (Lambda) Expressies waarmee je dan strongly-typed kan query'en. Met alle voordelen daarvan.quote:Op dinsdag 31 augustus 2010 13:44 schreef Tuvai.net het volgende:
[..]
Dat inderdaad. Veel 'gelaagdheid' komt er niet bij kijken in dit geval.
En NikkelCobalt, dat is inderdaad ook een idee. Dan ben ik echter nog meer werk aan het verrichten dan wat ik normaal altijd doe en derhalve ontgaat mij het nut een beetje van deze methoden met LinQ / Entity. Ook het 'na proberen te bootsen' van échte SQL queries vind ik erg omslachtig, vooral in geval van LIKE en OR operators. Om nog maar te zwijgen over de optimalisatie van de uiteindelijke SQL queries.
1 2 3 4 5 | IQueryable<Dinges> ResultsetQuery = from tDinges in Entities.Dinges where tDinges.Veld1 == StrongTypedWaarde1 where tDinges.Veld2 == StrongTypedWaarde2 select tDinges; |
1 2 3 4 5 | { ResultsetQuery = ResultsetQuery.Where(tDinges => tDinges.Veld3.Contains(TextboxVoorFilter3.Text)); } if (!String.IsNullOrEmpty(TextboxVoorFilter4.Text)) { ResultsetQuery = ResultsetQuery.Where(tDinges => tDinges.Veld4.Contains(TextboxVoorFilter4.Text)); } |
1 |
1 |
1 2 3 4 5 6 7 8 9 10 | where matches(filter1, x.Veld1) where matches(filter2, x.Veld2) ... select x bool matches(string filter, string value) { return string.IsNullOrEmpty(filter) || value.Contrains(filter); } |
Mja, noem het een kwestie van smaak, maar ik vind het een heel gedoe allemaal voor simpele handelingen. Ik prefereer liever mijn eigen, kinderlijk eenvoudige methode waar er met een Stored Procedure gecommuniceerd wordt, waar dan weer een SQL query in staat waar ik gewoon LIKE operators e.d. kan gebruiken. Om nog maar te zwijgen over het feit dat mijn codebehinds en BLLS nu bulken van 'Queries' en Lambda Expressions'. Mij is geleerd om databasezaken in de database te houden.quote:Op woensdag 1 september 2010 12:44 schreef OEM het volgende:
Complexe where-clauses kunnen toch ook gewoon in linq?
[ code verwijderd ]
Ik denk dat ie exact de essentie door heeft. Als je linq2sql gaat gebruiken in de presentatielaag wordt het een grote ellende die we nog kennen van sql queries in pagina's of de datasets variant ervan (1 op 1 kopieen van tabellen).quote:Op woensdag 1 september 2010 15:11 schreef NikkelCobalt het volgende:
Volgens mij geef je zelf al deels het antwoord op je problemen: meer gebruik maken van de database: Aan views en functies gedacht? Die herkent LINQtoSQL namelijk gewoon.
En verder denk ik dat je gewoonweg te weinig met LINQ hebt gedaan om er iets zinnigs over te zeggen. Situaties die je oplost met directe queries kun je net zo goed oplossen met LINQ(tosql).
Absoluut zijn er situaties waarin LINQ minder goed van toepassing is, maar de situaties die jij beschrijft noem ik niet direct problematisch. Het kostte mij overigens ook wel tijd om LINQ en LINQtoSQL onder de knie te krijgen
Om nog even een concreet te noemen: ik heb nu in een project (op LINQtoSQL) ook iemand meegemaakt die nog nooit van LINQ heeft gehoord. ASP.NET classic project was het, en die ging lekker allemaal stored procedures maken ipv een LinqDataSource gebruiken. Daar word ik dan weer wat minder vrolijk van
Wat ik overigens erg leuk vind aan LINQtoSQL is de databasereflectie die je standaard kunt doorlopen. (Hoewel de gebruikssituatie wel weer vrij specifiek is)
quote:Op dinsdag 31 augustus 2010 21:14 schreef Tuvai.net het volgende:
Nope, met die Strong Typed versie inclusief Lambda Expressions ben ik ook bezig. Maar ik vind het nog steeds vrij omslachtig. Om een heel goed voorbeeld te noemen: Ik heb een heel groot overzicht (een GridView) met een heleboel velden daarin, en op vrijwel al die velden kan 'gefilterd' worden. Die filters en de daarmee corresponderende velden bestaan uit allerlei DropdownLists, Textboxes, Checkboxes, enzovoorts. Nu heb ik om die GridView te vullen altijd het volgende stukje code (effe namen aangepast voor duidelijkheid):
[ code verwijderd ]
Oftewel een paar dingen kan ik in deze 'where clausules' al verwerken, met name de filters/selecties die altijd van toepassing zijn. Maar om bijvoorbeeld al die variabele filterwaarden er in te verwerken, krijg ik allemaal stukjes code als volgt:
[ code verwijderd ]
1 2 3 4 5 | IQueryable<Dinges> ResultsetQuery = from tDinges in Entities.Dinges where (StrongTypedWaarde1 == null || tDinges.Veld1 == StrongTypedWaarde1 ) where (StrongTypedWaarde2 == null || tDinges.Veld2 == StrongTypedWaarde2 ) select tDinges; |
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |