I'm working on an application in which we are trying hard to keep Separation of Concerns as strongly as possible. We're finding that the cross-cutting concern of security creates a number of complications.
However, it looks like these can be mitigated using attributes and Aspect-Oriented Programming.
I understand it as far as applying aspects to domain layer code, but what if you want to apply it to UI elements? For instance, what if I don't want to display a button when a user does not have permission to execute that functionality?
In our MVC application, at this point we'd have to write (pseudo-code follows):
<% if (user.CanSeeSomeData) { <%=Html.TextBox("MyTextBox") } %>
But we'd like to control the display with attributes a la AOP if possible.
Any ideas?
Also, if there are 3rd party, open-source tools that would be useful, those suggestions are welcome.
Aspect- oriented programming (AOP) allows weaving a security aspect into an application providing additional security functionality or introducing completely new security mechanisms.
Aspects enable the implementation of crosscutting concerns such as- transaction, logging not central to business logic without cluttering the code core to its functionality. It does so by adding additional behaviour that is the advice to the existing code.
Aspect Oriented Programming (AOP) compliments OOPs in the sense that it also provides modularity. But the key unit of modularity is aspect than class. AOP breaks the program logic into distinct parts (called concerns). It is used to increase modularity by cross-cutting concerns.
AOP (aspect-oriented programming) is a programming style that can be adopted to define certain policies that in turn are used to define and manage the cross-cutting concerns in an application. In essence, it's a programming paradigm that enables your application to be adaptable to changes.
I'd say that a view shouldn't contain much programming (or nothing at all). The idea of using AOP (or a la AOP) in a place where the P is forbidden doesn't look nice.
Let's design it in a different way. Usually views have some control keywords to do the basic stuff: conditions and loops. More intelligence and I'd say that you're mixing the controller role there.
So the if (user.CanSeeSomeData)
you put there, if it is in fact a simple flag. It's the way views should be.
When you were building the modelview object (the container where you put the information for the view). You could have used AOP to initialize/set that information with a nice attribute in that property for example.
You could ask for attributes instead of "ifs"
[UserCanSeeData]
<%=Html.TextBox("MyTextBox") %>
This looks like syntactic sugar, not real AOP. Any attempt to say that UserCanSeeData should have more than an if (like a database access to check user priviledges), is an attempt to move controller code into the view.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With