Do you prefer the clean approach of an AOP cache layer on top of your methods (any DAO or service method) OR do you prefer the total control approach of injecting a cache instance wherever you need?
I understand AOP gives you loose coupling and separation of concerns, but not so much flexibility, unless you are coding the method interceptors yourself.
I tend to like the IoC approach, because a cache instance can be easily mocked if you need to and with an instance of the cache you have total control and flexibility.
It is like logging. Who actually uses AOP for application wide logging?
This is the question about should we use "real" AOP at all (by "real" I mean quantification and obliviousness, so that you can enable aspects globally and 100% transparently for the system). My opinion is to avoid that 100% transparent solutions every time you can. If you're at the development stage, it will be better to design your system in the way that don't force you to do tricks like AOP weaving at intermediate code level.
At the other hand, it will be quite disturbing to write caching concern for every component/interface you need, no matter how you'll do it. The most obvious way which came to my mind is to have a caching Decorator class for each cached class - one thing done many times.
So the path I will try to follow is to have an idea of AOP done using some IoC extension based on dynamic proxying. When fetching an object from IoC, container can check in its configuration should the cache be applied for given type and if so, create an interface-based dynamic proxy with caching. This solution is not forcing you to write a lot of similar code and is less confusing than "real" AOP by its visibility in the source code. There are some implementations like this, but you haven't specified any language, so I can't offer any.
Related
I have been seeing this trend recently with some Spring Framework developers. When they create their Service classes they are not creating interfaces for them to implement and they are not using #Transactional in their service classes when they are definitely in need of transactions.
Is there a good reason for this?
And one more question, Spring Boot has Session In View set to be true. Why? I always thought that to be a really bad design, allowing for developers to be lazy and allow for N+1 queries to happen all the time and slowing down performance. If you know you are going to need it for the UI, why not query for it in the Service-Repository classes in the least amount of queries instead?
It's true that building Services with interfaces and class implementations has been under questioning lately. There a classic post about this: https://octoperf.com/blog/2016/10/27/impl-classes-are-evil/ .
About Transactions, for read operations the readOnly=true parameter should be included in the #Transactional annotation to make sure it is done properly. As for the write operations, of course the transaction management should be done with care and the #Transactional annotation is there to make sure it is done so. Not using it is certainly a code smell, since a transaction will happen nonetheless, but you just won't have control over it.
Session In View set to true is a code smell too, and it should be used in learning environments or short-term experiments only. Batching, among other possibilities, can and should be used to avoid the N+1 problem.
When we talk about spring (which ever module say jdbc), one of the reasons we use it is because it enables dependency injection and controls lifecycle of beans/classes. In programming, one of the most important fundamental is to code for interfaces rather than implementations, so today if I am using sql server driver v1, I can change it to v2 tomorrow if my code is written in such a way that it cares about Driver interface and not the implementations, then in what case would I ever need coding over configuration ?
The wording of your question seems a bit strange to me. Perhaps you are asking if there are any drawbacks to using Spring-like dependency injection. I can think of a few drawbacks, but whether these drawbacks outweigh the potential benefits of Spring is a matter of opinion.
Unfortunately, a Spring XML file is much more verbose than code to achieve similar (but hard-coded) initialisation of objects.
A programmer has to look not just at code but also at a Spring XML file to figure out what is going on. This, arguably, is a form of the Yo-yo problem.
One significant benefit of Spring is that it can be used to instantiate and configure any Java class (assuming the classes provide getters and setters). In particular, Java classes do not need to be polluted with the need to inherit from framework infrastructure classes. If you don't mind polluting classes with the need to inherit from framework infrastructure, then it is possible to have much more concise configuration files for instantiating and configuring objects. A case study illustrating this idea can be found in Chapters 9, 10 and 11 of the Config4* Practical Usage Guide. I am not proposing that the approach used in that case study be used for all applications, but I think it is a good approach to use when there is a complex, standardised API (such as for JMS) that is implemented by multiple products. In the case study, the approach results in a significantly easier-to-use API and eliminates some potential bugs from applications. Spring doesn't offer such benefits.
Section 9.4.2 of the Config4* Practical Usage Guide outlines a 9-step initialisation process for typical JMS applications. The framework library discussed in the case study ensures that those 9 steps are carried out in the correct order. It has been years since I looked at Spring so I might be wrong, but I don't think Spring has the flexibility to (easily or perhaps at all) enforce such a complex 9-step initialisation mechanism.
I was just starting to get comfortable with MVC when somebody mentioned IoC containers to me, and now I feel like I've fallen a few thousand feet and need to climb back up again. I was tempted to just ignore them, but then I read up on the Component Lifestyle. This seems like a big deal to me, as explained, uncommited changes to database updates might leak across requests if my repositories Lifestyle is set to Singleton instead of PerWebRequest.
So my question...is there a way to create the Component Lifestyle affect without using IoC containers, or is that the only option?
You can always create an implementation as a Singleton. However when speaking about a Repository I don't think there is a need. This is not the real purpose to using an IoC though. Using the IoC decouples the user of your code from the implementation itself. It makes testing easier as you can swap things in and out as you need too. Also, in my case I find it very useful for other purposes as well. Take caching for example. In my local dev I use Lucene.NET to provide my cache implementation with a disk based cache. Then when I push to my development and staging platforms I use the standard .net cache implementation. Then when I push to production I might use a Velocity or MemCached implementation. I don't have to do anything fancy to get from point A to point B since I am using StructureMap (my preferred IoC container).
It seems to be that Component Lifestyle is more of a design decision than an IoC decision. All three of the methods mentioned here for managing the life of an object can be done without IoC...but that might be an interesting side effect of an IoC (in some cases).
Is inversion of control essentially just retrieving a set of already instantiated objects? In theory. I guess more granular details as implemented by IoC frameworks like Spring have a lot more functionality, but in theory it seems like IoC containers operate like a collection of instantiated beans (in the Java world) and then you get access to those beans. Almost like you would with a collection Singleton objects?
It's partly getting hold of singletons in practice, yes. Some beans will be instantiated multiple times, whenever they're needed (depending on the configuration), but often you can make do with single instances - particularly if they're stateless once configured. I like the idea of data flowing "through" an application's plumbing after it's been properly hooked up.
The benefit is that the "singletoneity" is only present in the configuration, not in the code, which makes the system more testable and flexible. The difference in terms of how you view (and expose) the dependencies with your app is huge.
Although the answer has already been accepted, I will elaborate a little more:
Initially spring was mostly about singleton management. with the introduction of custom scopes came the web specific scopes and the ability to create your own custom scopes. Leaning on AOP features this also allows you to "stay singleton" for as long as possible, because it uses a technique known as scope proxying. This can let you introduce a scoped object right in the middle of a chain of singletons - a feature you'd often be using threadlocals for.
So I'd say it's about tight control of instance creation, to make sure everything is done only the required number of times, and preferably only the construction that is necessary is done for each request. Singleton management was the old days.
We have started to use spring aop for cross cutting aspects of our application (security & caching at the moment).
My manager worries about the performance impact of this technology although he fully understands the benefits.
My question, did you encounter performance problems introduced by the use of aop (specifically spring aop)?
As long as you have control of your AOP I think it's efficient. We did have performance problems anyway, so by own reasoning we were not fully in control ;) This was mostly because it's important that anyone that writes aspects has full understanding of all the other aspects in the system and how they interrelate. If you start doing "smart" things you can outsmart yourself in a jiffy. Doing smart things in a large project with lots of people who only see small parts of the system can be very dangerous performance-wise. This advice probably applies without AOP too, but AOP lets you shoot yourself in the foot in some real elegant ways.
Spring also uses proxying for scope-manipluations and thats an area where it's easy to get undesired performance losses.
But given that you have control, the only real pain point with AOP is the effect on debugging.
If performance is going to be a concern, we have used AspectJ to great effect.
Because it uses bytecode weaving (compile time vs. runtime makes quite the difference) it's one of the fastest AOP frameworks out there. See: AOP Benchmarks
When I used it, I didn't - but then my application isn't your application.
If you use it for calls which are used in a very tight loop, there's the opportunity for a significant performance hit. If it's just used to check security once per request and cache various things, I can't see how it's likely to be significant - but that's why you should profile and benchmark your app.
I realise that "measure with your app" probably isn't the answer you were looking for, but it may well be the one you guessed you'd get :)
If you are using proxy-based AOP, you are talking about 1 additional Java method invocation per aspect applied. The performance impact there is pretty negligible. The only real concern is the creation of the proxies but this usually happens just once on application startup. The SpringSource blog has a great post on this:
http://blog.springsource.com/2007/07/19/debunking-myths-proxies-impact-performance/
In theory, if you use AOP do to what you could do with hard coupling, there is no performance issue, no overhead and no extra method calls unless you weave for nothing. AOP Framework offers you a way to remove the hard coupling and factorize your cross-cutting concern.
In practice, AOP Framework can introduce 3 types of overhead:
fire-time
interception mechanic
consumer integration (way to develop an advice)
For more details you can refer to when-is-aop-code-executed.
Just be careful how you implement an advice because transversal code is a temptation for boxing/unboxing and reflection (expensive in term of performance).
Without an AOP Framework (hard coupling your cross-cutting concerns) you can develop your presumed advices (dedicated for each treatment) easier without boxing/unboxing and reflection.
You have to know that most AOP Framework don't offer the way to avoid totally boxing/unboxing and reflection.
I developed one to respond to most of missing needs concentrated to 3 things :
user friendly (lightweight, easy to learn)
transparent (no breaking code to include)
efficient (no boxing/unboxing, no reflection in nominal user code and good interception mechanic)
You can find my open source project here : Puresharp API .net 4.5.2+ previously NConcern .NET AOP Framework
11 years after the question, look how degenerated this situation is.
Example: the vast majority think it is ok and normal to put a simple #Transactional spring java annotation to some method and let spring do the bridge between caller and callee proxied components. Now they have 20+ stackframes of undebuggable 'magic' code. The JIT compiler is rapidly exceeded and can no longer attempt inlining, or ends up bloating memory with tons of generated classes.
There is no limit to lazyness in this era of 'framework users'. No wonder e2e times for trivial http calls went from 100ms to 10 seconds. No wonder you need 2GB to run a lousy servlet container that used to run in 128MB. And don't get me started on the cost of logging exception stacktraces...
Have you ever thought about an AOP tools that adding aspects to object at runtime when you need? There is one for .net "Add Aspects to Object Using Dynamic Decorator" (http://www.codeproject.com/KB/architecture/aspectddecorator.aspx). I believe you can write a similiar one for Java.
If you are using some one framework for aspects there can be some performance issues .Next if you are creating abstraction above some one framework and aspects handling is done from framework then its very difficult to find out the cause of the problem relating to performance issues . If you are really concern about performance and small time slice concern more ,i suggest to write own aspects .No one want to reinvent the wheel but sometime for better it can be best.You can write own implementation of AOP alliance abstraction .
i have used spring AOP in a batch process in my current project to transaction manage a database.
At first, it was figured that there wouldn't be a performance problem, but we didn't figure into the equation that we called the database thousands of times. one aspect call in aop doesn't affect performance much, but multiply that by thousands, and it turns out the new system was worse than the old one, due to these extra method calls.
I'd say that aop is a great system to use, but try to take note on how many methods calls are added to your application