Microsoft .NET - deel 1

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

Je kunt gewoon een WebRequest doen (of afgeleide daarvan) en dan via een

XmlDocument doc = new XlmDocument();
doc.LoadXml(<hier je opgehaalde xml code>);*

dat behandelen.

(LoadXml was uit mn hoofd, kon ook wel LoadString ofzo zijn).

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?

quote:

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?

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)

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)

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..

[ Bericht 9% gewijzigd door Tarabass op 31-07-2010 10:23:02 ]

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..

Je ziet heel vaak dat er processen geimplementeerd zijn op de manier van:

• systeem 1 doet iets
• systeem 1 trapt systeem 2 af
• systeem 2 doet iets
• systeem 2 trapt systeem 3 af
• enz

Dit creert een ketting van systemen die aan elkaar hangen, wat zo ondoorzichtelijk is als maar kan en dus niet te onderhouden is.

Maar aangezien dit een technisch verhaal is (geen functioneel proces) speelt dat allemaal een stuk minder. Hoewel ik nog steeds het in de BL zou oplossen aangezien je functionele zaken wil loggen ("Aanmaken NIeuwe Gebruiker") ipv iets technisch ("new record in table users", "new record in table user_details", "new record in table user_settings", etc).

Of je nou een voor alles wat je wilt loggen een trigger moet maken/configureren of een extra regel code in je BL maakt niet zo heel veel uit (ervanuitgaande dat je in je BL een mooie functie CreateNewUser hebt). In de BL is deploymenttechnisch eenvoudiger t.o.v. CLR dll's in je db.

Zo kijk ik er een beetje tegenaan. Maarrrr... CLR in de database moet je een keer gedaan hebben, dus gewoon 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

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.

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.

Nog even als toeveoging op mijn vorige reactie:

Als je networkcredentials niet geaccepteerd zouden worden, dan zou je een 401-NotAuthorized krijgen. In dit geval ben je wel authorized (want credentials doen er niet toe), maar zonder token mag je de data niet zien, en dus krijg je een 403-Forbidden.

Wat betreft die picassa, daar heb ik geen ervaring mee, maar heb wel ervaring met uitlezen google analytics api, en daar moet je idd een post doen om een credential key te krijgen, die je vervolgens kan gebruiken om via rest de data uit te lezen.

Zijn er overigens nog meer Umbraco gebruikers hier? Echt heerlijk systeem, gebruik het al vele jaren, en op het werk hebben we al ruim 10 implementaties gedaan, ben in mei ook level 2 gecertificeerd

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.

Ah, dat maakt het wel duidelijker, en logischer idd.
Ik zal dat binnenkort eens proberen.
Dank je wel

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 object 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?

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?

Klinkt alsof System.Collection.Generic.Dictionary nodig hebt.

Best practice is om je code eerst zo "mooi" mogelijk te maken (=onderhoudbaar), en daarna pas gaan optimaliseren voor performance.

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.
Al is dit met uitlezen misschien wel weer sneller dan de find-optie van een list.

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.

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.

Als je LINQ gebruikt: IEnumerable<T> heeft zelfs een speciale extension method om een collectie te indexeren op 1 bepaalde property van een object, waardoor je het volgende zou kunnen schrijven:

quote:

Al is dit met uitlezen misschien wel weer sneller dan de find-optie van een list.

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).

Maar ik zou altijd voor de dictionary gaan, bij minder dan 10 elementen zijn beide oplossingen "ongeveer even snel", terwijl bij meer de dictionary veel sneller is.

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

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

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.

Gewoon een non-sql database

Las daar van de week iets over op webwereld. CouchDB enzo, maar das apache.
Kwam wel RavenDB tegen, dat klinkt ook wel interessant.

Ik ben momenteel even aan een klein freelance project aan het 'bijspringen'. Het grove 'frame' van de applicatie stond er al en er moet nu van alles ingebouwd worden. Ik ondersteun een team van 3 developers. Nu werken deze developers allemaal met het Entity framework, en is mij gevraagd om daar ook zo veel mogelijk rekening mee te houden. Geen probleem hoor, ik pas me wel aan.

Maar tering, wat een rotzooi. Kan met niet voorstellen dat mensen dat hele Entity en LINQ-to-SQL / LINQ-to-object gebeuren fijn vinden werken. Okee, je maakt ongelooflijk snel d.m.v. een ADO.NET Entity model een soort van DAL en je hebt meteen interactie met je database. Maar ik ben er echt geen voorstander van om in uiteindelijke WebForms pas de 'queries' samen te stellen. Doet me een beetje denken aan mijn PHP 3.0 tijdperk. Sowieso die 'queries'.

Liever heb ik Database -> DAL -> meerdere BLL's -> Presentatie.

Wat houdt je tegen een repository te schrijven? Dat is gewoon je DAL (in dit opzicht, niet letterlijk). Voordeel van een repository is dat je ook nog een speciale implementatie van je repository (repository is meestal een interface) kan maken die niet van een database gebruik maakt maar gewoon hardcoded data teruggeeft. Voor het testen dus.

Dus dan heb je het volgende:

Database -> ORM/DAL LINQtoSQL/EF -> Repository-> BLL -> Presentatie
Database -> SQL -> DAL -> Repository -> BLL -> Presentatie