|
|
|
Community Member
|
|
Ok, I know its probably next to impossible to change someone's mind if they are stubborn and have their mind made up. I've been told, with a resounding "NO" when asked about using any library for AOP. This applies to any "non-microsoft" library that supports the modification of the base IL...
So, how do you guys/gals go about convincing your bosses? Have you had much resistence to this?
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
That's a general problem of Microsoft shops I am afraid.
If you were asking about AOP in general, then I like to cite a few facts:
- AOP is 15 years old.
- There are BIG industry projects using AOP, done by very serious and conservative companies like Siemens, in very regulated markets like US healthcare.
- Even ABAP (the SAP language) and COBOL (yes!) have AOP extensions -- these are not languages for geeks.
As for PostSharp in particular, you can start by using that for something that is not vital (for instance: tracing or performance monitoring -- you can always remove the feature in case of trouble), gain confidence, then use it for more vital functions.
Also, PostSharp is open source, reasonably documented, so you should be theoretically always correct a trouble. And, practically, since I makes partially a living out of that, you can also hire me to solve any problem <!-- s:geek: -->  <!-- s:geek: -->.
Good luck!
|
|
|
|
|
Community Member
|
|
The approach I use is proving that PostSharp adds stability and decreases development time.
Cross-cutting concerns are separated and handled by your PostSharp aspect implementation, making code management easier. Call it separation of concerns coupled with increased modularity which decreases repetitive code. A good example is logging code or argument validation (think DbC).. if you have a bug in either and you use Laos, you have exactly one place to look, the aspect code, and not the million places it has been applied. In contrast, if you just copy and paste the buggy code to apply it across your project.. that's a very different scenario.
Patterns.. an extension of the previously mentioned.. a lot of the time can be saved and problems answered with this technique. Perhaps a little education will help nay-say-ers... http://www.youtube.com/watch?v=cq7wpLI0hco This is a presentation by a very knowledgeable individual. It is geared toward Java and AspectJ, but expresses the value of AOP by implementing the decorator pattern using a simple drawing application as an example, and he touches on the problem of cross-cutting concerns and code ownership.
Other attempted shoot-downs:
We don't want any 3rd party references. You can solve this with ILMerge. You won't have to ship a non YourCompany.Module.dll.
Too complex. This is a hard one. Compared to VB6, .NET is way too complex. And WAY better. This is likely a stubborn or ignorant reason that was shot from the hip. Then it becomes about proving AOP. AOP has been around, as Gael pointed out, much longer than most people realize. Even Microsoft uses AOP. Look at their patterns and practices site. http://msdn.microsoft.com/en-us/magazine/dd727513.aspx. IMHO PostSharp is easier for most developers to understand and use than Unity, and it's compile-time, but it proves that they embrace AOP.
Bloat/Performance. If your manager understands PostSharp then he will know that it adds code to your assembly. If performance is a major concern, then Laos may not your answer, but PostSharp still is. Take a look at the two tracing sample and the logging example to see how the problem can be solved by Laos at a high level, or by direct weaving at a low level. If direct weaving is still not fast enough, you probably should be coding in unmanaged C++, in which case the concern is invalidated. Otherwise it is worth pointing out that applying the same pattern to several places in your code is pretty much same amount of MSIL as having Laos apply that pattern for you. The only real overhead is the static constructors and load-time deserialization. A lot of attention has been paid to this, apparent by particular features such as allowing you to chose your serialization class. After careful scrutiny it should become clear that the benefits to the project outweigh the (IMHO negligible) run-time cost by far.
Lastly, as Gael also mentioned... it's supported. CodingGlove is the company behind PostSharp, and they are committed to the success of PostSharp. I am repeating this fact because I have experienced it first hand. This product is available as GPL or commercially licensed. As a non-commercial customer you will find that your questions will be answered quickly... and you will also find that if you happen to find a bug, or, in my case, just had a requirement that was not quite met, your problem will be resolved quickly. A while ago as I using PostSharp for a contract customer and I ran into some issues and to my delight, my questions were answered very quickly, and when I found something I needed changed in the source code (not a bug), the turn around time for me was one day. (proof? http://www.postsharp.org/forum/postsharp-laos/change-internal-weavers-and-dependencies-public-t364.html) I would consider the support I received to be first class. Not only that, but the feature I was creating made it into the next release candidate. And it's worth noting that the company I was contracting with built only internal products, and therefore stuck with the GPL license, meaning that the support I received was free. If you're a commercially licensed customer, you can expect that CodingGlove will go above and beyond.
Lastly, and most cynically, I wonder about the conversation that had taken place with your manager about the switch to .Net? To me, AOP is to OO as OO is to procedural code. If your manager can recognize the value of OO to a development department, then he or she should immediately recognize the value of AOP. If not, my guess is lack of understanding.
First prove AOP (as it is already proven). In fact, conceptually, AOP is 25 years old.. at least since 1984, and if Xerox and IBM like it....
http://www.google.com/views?q=view%3Atimeline+Aspect+Oriented+Programming&btnGt=Search&hl=en
Then promote PostSharp. Call it a commercial product. Even though it is open-source, it is NOT an open-source project. Some people may not understand the difference, so call it commercial since it is not something anyone can contribute to, unless of course they get hired by Coding Glove. Calling it an open-source project may be equated with "anyone and everyone has been touching the code.. who knows if it's good". That's a debate, and it's best to make statements that can not be debated by someone without the appropriate knowledge.
* All of this is my humble opinion; I am a supporter of the PostSharp project. I recognize the power it offers from many angles, whether it's project management, development lifecycle, architecture, or just developer ease. I fully endorse this project.
(I know my two cents came a little late, but I have been in this boat and have succeeded, so I wanted to try to help).
Chris Hanson
Software Architecture Consultant
Madison, WI, USA
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
Hi Chris,
Thank you for this comprehensive answer.
-gael
|
|
|
|
Contacts
| Terms of Use |
Privacy Policy