mboost-dp1
.NET AOP Static Weaver
Dem som interesserer sig for den slags (og det er nok en meget meget lille gruppe) har nok observeret at udvalget af sådanne tools er meget begrænset.
Jeg har selv brugt AspectDNG i mange år. Og det virkede perfekt. Men forfatteren droppede projektet i februar 2008 og det virker simpelthen ikke med nyere .NET versioner.
Så er der et helt nyt projekt SheepAspect/SheepAOP som ser meget lovende ud. Men jeg kan simplthen ikke få det til at virke. Intersserede kan selv forsøge at hente det fra CodePlex eller via NuGet.
¤"%!¤%!¤!
Man kan jo ikke leve uden AOP Static Weaver.
Så det er endt med at jeg har valgt at skrive min egen.
Resultatet kan ses her:
http://www.vajhoej.dk/arne/opensource/yaaopf/
Den mangler stadig lidt her og der, men der er da noget som virker.
Jeg har selv brugt AspectDNG i mange år. Og det virkede perfekt. Men forfatteren droppede projektet i februar 2008 og det virker simpelthen ikke med nyere .NET versioner.
Så er der et helt nyt projekt SheepAspect/SheepAOP som ser meget lovende ud. Men jeg kan simplthen ikke få det til at virke. Intersserede kan selv forsøge at hente det fra CodePlex eller via NuGet.
¤"%!¤%!¤!
Man kan jo ikke leve uden AOP Static Weaver.
Så det er endt med at jeg har valgt at skrive min egen.
Resultatet kan ses her:
http://www.vajhoej.dk/arne/opensource/yaaopf/
Den mangler stadig lidt her og der, men der er da noget som virker.
#1
Og inden nogen tror at jeg bare er et megafjols siden jeg ikke kan få SheepAspect til at fungere, så se lige denne kode:
http://sheepaspect.codeplex.com/SourceControl/chan...
Ikke helt production ready efter min mening!!
Og inden nogen tror at jeg bare er et megafjols siden jeg ikke kan få SheepAspect til at fungere, så se lige denne kode:
http://sheepaspect.codeplex.com/SourceControl/chan...
static int Main(string[] args)
{
try
{
//var configFile = args[0];
var configFile = @"D:\Dev\Experiment\TestSheepAspect\TestSheepAspect/bin/debug/SheepAspect.config";
var directoryPath = Path.GetDirectoryName(configFile);
Ikke helt production ready efter min mening!!
#4,#5,#6
Derudover er der en glimrende "Ret indlæg" funktion, så man ikke unødigt smider 3 posts med svar til samme. :D
Dog er jeg enig i, at der godt kunne være en "Dette retter sig til 'disse' behov", idet der nævnes en specifik 'mangel'.
Evt. lave en liste over ting som programmet(?) ikke kan, som ellers ikke er helt unormale i 'miljøet'.
'Mangler' og 'ting som arnes ikke kan' bør ikke betragtes negativt, da jeg fint ved at hvis man ikke selv skal bruge det, så ryger det ikke i de tidligste releases. :)
* De mange citationstegn er ganske enkelt fordi, at jeg endnu en gang ikke kan følge med. :P
Derudover er der en glimrende "Ret indlæg" funktion, så man ikke unødigt smider 3 posts med svar til samme. :D
Dog er jeg enig i, at der godt kunne være en "Dette retter sig til 'disse' behov", idet der nævnes en specifik 'mangel'.
Evt. lave en liste over ting som programmet(?) ikke kan, som ellers ikke er helt unormale i 'miljøet'.
'Mangler' og 'ting som arnes ikke kan' bør ikke betragtes negativt, da jeg fint ved at hvis man ikke selv skal bruge det, så ryger det ikke i de tidligste releases. :)
* De mange citationstegn er ganske enkelt fordi, at jeg endnu en gang ikke kan følge med. :P
Jeg ville bruge PostSharp ( http://www.sharpcrafters.com/ ) hvis jeg skulle bruge mere AoP i .NET end jeg allerede gør.
Det er AoP, det er hvad det kan :-) Arne har valgt at lade det matche AspectDNG, så du kan jo evt. læse Quickstart siden på http://aspectdng.tigris.org/nonav/doc/index.htmlMort (4) skrev:Jeg vil lige tilføje at hvis det er intentionen at andre skal bruge det du har lavet, er det måske en god idé at forklare hvad det kan.
Mort (4) skrev:Jeg vil lige tilføje at hvis det er intentionen at andre skal bruge det du har lavet, er det måske en god idé at forklare hvad det kan.
Mort (5) skrev:Og så kan det måske være en god idé at lave et eksempel på hvordan man bruger det, så andre kan beslutte sig for om det er noget som er noget for dem.
Overskriften fortæller faktisk hvad det er.
Hvis man altså ved hvad en AOP static weaver er for en tingest.
Hvis man ikke ved det er man naturligvis på bar bund.
Den ultra korte version kommer her:
AOP = Aspect Oriented Programming.
AOP er et supplement til OOP. OOP er god til at modellere business logic i. Men en masse praktiske programmering ting såsom logging, transaktions styring, caching, access control etc. passer dårligt ind i OOP modellen. Man ender typisk op med at gentage en masse kode i hundredevis af klasser og metoder. Ideen i AOP er at man definerer den slags separat og så væver dem ind i ens pæne OOP kode.
Man skelner mellem:
static weavers - som væver ved build
dynamic weavers - som væver runtime
ADVARSEL: man kan lave nogle meget elegante løsninger med AOP, men man kan altså også nemt gøre det umuligt at forstå flowet i ens applikation fordi den kode der udføres ikke er den samme som ens pæne business logic baserede OOP kode.
Mort (6) skrev:Derudover så kan det være en fordel at fortælle hvad det er det program du har lavet gør anderledes end de andre programmer du refererer til.
arne_v (1) skrev:Jeg har selv brugt AspectDNG i mange år... og det virker simpelthen ikke med nyere .NET versioner.
arne_v (1) skrev:Så er der et helt nyt projekt SheepAspect/SheepAOP ... Men jeg kan simplthen ikke få det til at virke.
Mit program virker.
Mnc (7) skrev:Evt. lave en liste over ting som programmet(?) ikke kan, som ellers ikke er helt unormale i 'miljøet'.
Mnc (7) skrev:'Mangler' og 'ting som arnes ikke kan' bør ikke betragtes negativt, da jeg fint ved at hvis man ikke selv skal bruge det, så ryger det ikke i de tidligste releases.
ZIP filerne indeholder en meget kortfattet "Getting started" som indeholder en list over hvad der ikke er testet og derfor formentligt ikke virker. Og det er en rimelig lang liste!
Forresten så kan weaving bruges til mange ting, f.eks. http://code.google.com/p/notifypropertyweaver/ , som er et *must have* ved alt UI programmering.
Men netop logging er altså en stærk feature ved AoP.
Men netop logging er altså en stærk feature ved AoP.
Windcape (10) skrev:Jeg ville bruge PostSharp ( http://www.sharpcrafters.com/ ) hvis jeg skulle bruge mere AoP i .NET end jeg allerede gør.
arne_v (2) skrev:
Jeg skal lige tilføje at weavers der kræver attributter i input assembly ikke kan bruges til mine formål.
(bare inden nogen sidder og tænker - hvad med XYZ)
PostSharp kræver mig bekendt attributter i input.
Der er to forskellige paradigmer:
- input definerer selv hvilke pointcuts de matcher
- pointcuts defineres udfra signaturer i aspects
Det første synes jg simpelthen ikke er godt nok.
Hvis man alligevel skal ind manuelt og tilføje attributter, så kunne man stort set lige så godt tilføje kode kald.
Man får først fuld udbytte af AOP hvis man kan definere pointcuts for signaturer med wildcard i sin aspects.
Windcape (11) skrev:Det er AoP, det er hvad det kan :-) Arne har valgt at lade det matche AspectDNG, så du kan jo evt. læse Quickstart siden på http://aspectdng.tigris.org/nonav/doc/index.html
Der er også et lille eksempel i "Getting started" i ZIP filerne.
#12
Læs evt.:
http://www.eksperten.dk/guide/1213 (Java og AspectJ)
http://www.eksperten.dk/guide/1214 (C# og AspectDNG)
Læs evt.:
http://www.eksperten.dk/guide/1213 (Java og AspectJ)
http://www.eksperten.dk/guide/1214 (C# og AspectDNG)
Problemet er bare at en string signatur ikke har nogen direkte relation til et stykke kode. Dvs. ved refactoring matcher ens signatur måske ikke længere.arne_v (16) skrev:Man får først fuld udbytte af AOP hvis man kan definere pointcuts for signaturer med wildcard i sin aspects.
Hvis man endelig skulle, tror jeg at jeg ville gå efter en slags builder, ala. Moq, hvor man kan definere strong-typed matches.
Dog kan jeg godt se at det muligvis ville give problemer med aspects på constructoren.
Windcape (20) skrev:Problemet er bare at en string signatur ikke har nogen direkte relation til et stykke kode. Dvs. ved refactoring matcher ens signatur måske ikke længere.
Det er klart en risiko.
Men at skulle definere aspects for lad os sige 1000 klasser med 10000 members gør altså wildcard meget attraktivt.
Eksempel:
public class AspectsSample : AspectRunner
{
public override void Setup()
{
AroundCall<Sample>(x => x.Test(It.Any())).Intercept(jp =>
{
Console.WriteLine("Code before calls to '.. Sample.Test(..)'");
object result = jp.Proceed();
Console.WriteLine("Code after calls to '.. Sample.Test(..)'");
return result;
});
AroundBody<Sample>(x => x.Test(It.Any())).Intercept(jp =>
{
Console.WriteLine("Code before body of '.. Sample.Test(..)'");
object result = jp.Proceed();
Console.WriteLine("Code after body of '.. Sample.Test(..)'");
return result;
});
}
}
Jeg har lige smidt en version 1.1 op:
Desværre kan jeg konstatere at advices på metoder som selv er generiske ikke virker. Ved ændring af IL koden bliver resultatet invalid.
1.1
Add:
Instance, SkipCall and Context properties in MethodJoinpoint
Improve wildcard support to allow arbitrary usage of *
Support generic data types as arguments and return type
Support at AtExceptionAdvice
Desværre kan jeg konstatere at advices på metoder som selv er generiske ikke virker. Ved ændring af IL koden bliver resultatet invalid.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund