Kurser och utbildning av IT-proffs och systemutvecklare

i Sök

Cornerstones utvecklarblogg

Alla Taggar

All Tags » AOP   (RSS)

  • Isn't it boring to write crosscutting concerns?

    To make sure we have clean code and make it easy for us to maintain, we should try to be lazy and reuse code as much as possible, we should also avoid redundant code. But when it comes to crosscutting concerns, we have to be redundant, or? What code is mostly redundant in our code? I will assume that code to check security and logging exceptions are the most redundant code we write. A method should only do one thing, but we can't skip crosscutting concerns, we need it. So basically several method will do more than one thing. Wouldn't it be much better if we only focus on the core concern and skip the crosscutting concerns when we write our code? How can we skip the crosscutting concerns but still has it? The answer is Aspect Oriented Programming (AOP). The PAG team has a Policy Injection Application BLock (PIAB) which we can use to intercept our crosscutting concerns into our code, we also have Spring.Net and some other frameworks. By using AOP frameworks we don't need to write the same code for logging exception etc over and over again, we will also have a much cleaner code, and our focus will only be the core concern. Oh, I feel so lazy, but why should I spend time to write code that do the same thing over and over again, it's so boring, isn't it :P Are you tired of writing crosscutting concerns over and over again, and do you use AOP today?
  • WCF As The Next Object Runtime in .NET?

    The more I work with Windows Communication Foundation the more I see it as an extraordinary piece of technology. With the ability to easily extend and intercept messages it's much more dynamic than any other programming stack for distributed applications I've come across (thus far). Apparently Juval Löwy is of the same opinion. Via UDI ( http://udidahan.weblogs.us/2007/12/29/wcf-everywhere-not-on-my-watch/ ) I found an ARCast with Juval and Ron Jacobs where Juval has the radical suggestion that WCF should be the object runtime of .NET, he wants every class to be a WCF service. You can see the full cast over here: http://channel9.msdn.com/ShowPost.aspx?PostID=347010

    His argument is that in WCF it's really easy to apply cross-cutting concerns like transactions and security to objects without burdening the developer with the plumbing code. A lot of code that is being written is just plumbing and WCF can help you reduce the amount of plumbing code.

    For instance; In a recent project, with just a couple of lines of code, I managed to extended the WCF message dispatch mechanism to automatically create a new LINQ To SQL DataContext and dispose it for every call to an operation. Once the code for handling the cross-cutting concern was written, it was really easy to apply a decorator for each operation that should have that particular behavior:

    [AutomaticDataContext]
    public List<Customer> GetTop10Customers() { . }

    Now where have I've seen this capability before, I wonder..

    Oh wait I got it: In AOP!

    I agree with Juvals argument that often the level of abstraction for plumbing is too low, it needs to be higher and we need a better way of applying cross-cutting concerns across our systems. But I'm not sure that WCF is the solution, not in its current state anyway.

    WCF and the functionality there in is mainly architectured for distributed scenarios, Juval says it the best himself when he in the ARCast calls the WS-* specs for "Wire Specs" I.e what goes on the Wire. Well, YAGNI is all I have to say about that.

    Instead, I would like to see Microsoft open the instantiation and dispatch mechanism of the CLR for extensibility. WCF would benefit from that, so would all the LINQ implementations and everything else you might come across that have cross-cutting concerns. Additionally we would at least be able to build intercepting runtimes even if it wouldn't be fully fledged AOP frameworks.




    Bloggtoppen.se Computers Blogs - Blog Top Sites
  • Remove code smell with AOP

    During the last years you have probably heard about Aspect Oriented Programming (AOP). Different people like or don’t like AOP. I’m one of them who like AOP. As you may now VB.Net and C# are object orientated languages and with object oriented programming (OOP) you want to reduce code duplication, code duplications smells badly. If you need to do code duplication you are probably doing something wrong with the implementation of your domain model. With OOP you can generally eliminating code duplication, but there are some cases where we can’t avoid it, for example take a look at this code:

    public class MyClass
    {

           public void MyBusinessMethod1()
           {
                 CheckSecurity();
                 //Place your code here
           } 

           public void MyBusinessMethod2()
           {
                 CheckSecurity ();

                 //Place your code here
           } 

           public void CheckSecurity ()
           {
                //Place the code for the security check here
           }
    }

    The code above has code duplications, where CheckSecurity method is added to each business method. This code duplication is not only painful to write, it could also make the code smell bad and make the code less maintainable. With the refactoring Move Method "A method is, or will be, using or used by more features of another class than the class on which it is defined", the CheckSecurity method could be moved into the infrastructure and the new class where the method is located will be the only place where the CheckSecurity is located. Centralization of code will make it easier to maintain the code. Even if you use the Move Method, the MyClass still use code duplication. Unfortunately, OO doesn’t help us removing the code duplication. You could of course use code generation to manually avoid adding the CheckSecurity to each method where the security check needs to be done.

    AOP crosscutting can be used to address concerns such as the security checks and of course other application specific concerns too, for example, you could make Lazy Load work without needing to have a dependency to your Repository or data mapper within the domain objects. With AOP, you could remove the code duplication from the code example above, and create a method interceptor where you add the CheckSecurity method. The following is a pseudo code of an interceptor:

    public class MySecuirtyInterceptor : MethodInterceptor
    {
          public object Invoke(MethodInvocation invocation)
          {
                CheckSecurity (); 

                //Call next interceptor
                Return invocation.Proceed();
          }
    }

    By using an AOP framework where you could define a set of methods (pointcuts) that should use the security interceptor, you could easy remove the code duplication, and remove the security concern from the developer, and add it later, if it’s required. The The MyClass in the first example could look like this if we use AOP and the MySecurityInterceptor above:

    public class MyClass
    {
           public void MyBusinessMethos1()
           {
                 //Place your code here
           }

           public void MyBusinessMethos2()
           {
                 //Place your code here
           }
    }

    Developers don’t need to add the CheckSecurity method. If we need to have a security check before executing the method, you could add a pointcut later for the methods that should call the CheckSecurity. Some sophisticated AOP frameworks can use regular expression or other wildcard syntax for the pointcuts. Pointcuts is a set of Method, Fields or Throws (When a particular exception is thrown) that should invoke the interceptor method. Those pointcuts could for example be specified within a XML file.

    You can also use AOP to do some logging or other operations before or after a method has bean invoked, or a field has been set, or even when en exception was thrown. The developer who are creating the business methods, don’t need to call a method that will for example log a message, it’s something that could be specified within an XML file. By using AOP you could solve problems that could not be done with OOP. You can not only reduce the smell of bad code, you could also reduce time it takes to add the duplication of codes etc. I hope this post gave you some more information about how you can use AOP to solve some problems that can’t be easily done with OOP.


Den här bloggen

Syndication