I created a custom attribute class that will check the system security and throws an authentication exception if there is a security error.
public class EntityChecker: System.Attribute
{
public EntityChecker(int entityId)
{
// doing some logic to check if the entityId is allowed to be inserted
}
}
I want to use this custom attribute as a declaration to an entity addition function and I want to pass a variable from the function to the attribute constructor. can something like this be done?
[EntityChecker(entityId)]
public int AddNewEntity(entityId)
{
// logic of entity addition
}
Can something like this be done ?!
No. Constructor parameters in attributes must be resolved at compile time. They are intended as metadata on the type or method itself, not something that would be used per call or per instance.
Given your description, an attribute is likely not an appropriate way to handle this. Since you want to run extra code that happens per call, you will need a different technique. For example, you could pass a delegate, ie:
public int CheckedAddEntity(int entityId, Func<int, int> funcToAdd)
{
// Perform your checking on entityId here
return funcToAdd();
}
This would let you then call via something like:
int result = CheckedAddEntity(entityId, AddNewEntity);
In this case, I recommend looking at Aspect-Oriented programming. It is a different way of doing code, but one that allows you to re-use the boilerplate logic (e.g. authentication) throughout. You might have to design your attribute a little bit differently, but all of the logic can be put into an "aspect" which then gets compiled automatically into the code when you build the project.
I personally use PostSharp, although I know there are others out there. They have a free license available for development; as long as you don't require advanced functionality, it's very cost-effective.
http://www.postsharp.net/blog/post/5-Ways-That-Postsharp-Can-SOLIDify-Your-Code-Authorization
Related
I've been struggling to find examples of how to write a custom attribute to validate method parameters, i.e., turn this form:
public void DoSomething(Client client)
{
if (client.HasAction("do_something"))
{
// ...
}
else
{
throw new RequiredActionException(client, "do_something");
}
}
into this:
public void DoSomething([RequiredAction(Action="some_action")] Client client)
{
// ...
}
As far as I can tell, I need to add this attribute to my custom attribute, but I'm at a loss on how to access the decorated parameter Client:
[AttributeUsageAttribute(AttributeTargets.Parameter)]
public class RequireActionAttribute : System.Attribute
{
public Type Action {get; set;}
public RequireActionAttribute()
{
// .. How do you access the decorated parameter?
Client client = ???
if (!client.HasAction(Action))
{
throw new RequiredActionException(client, Action);
}
}
}
You're applying it correctly - but an attribute basically doesn't know the member it refers to. This definitely makes life harder.
Not only does it not have access to the member that it refers to, but that member would be a ParameterInfo, not a Client - there's no easy way of accessing the value of a parameter externally. Your method would need to call some helper code, passing the value of client in order to handle it appropriately... or you need to hook into the code which is going to call your method to start with, in order to notice the attribute.
It's not clear exactly how you were hoping to use this, but it may well be that you need to change your design significantly.
Attributes are not enough for doing it.
If I understood you correctly you want to add an attribute on a parameter in order to validate it at run time and that is impossible only with attributes.
It is impossible because attributes are only "metadata" and not executed code.
You will need some "real" code to read it and act accordingly. That code can be injected at compile time or you can hook into the function execution.
Attributes probably should be put on the method itself. When I was searching for the solution I found the following link and the way it uses interceptor seems even better http://www.codinginstinct.com/2008/05/argument-validation-using-attributes.html
Thanks for looking!
Background
I have an extension method that is used to wrap a given method in a try/catch and I am adding code for logging any caught exceptions:
public static T HandleServerError<T>(this Func<T> func)
{
T result = default(T);
try
{
result = func();
}
catch (Exception ex)
{
//******************************
//Code for logging will go here.
//******************************
ErrorHandlers.ThrowServerErrorException(ex);
}
return result;
}
Here is how the method is called:
var result = new Func<SomeClass.SomeType>(() => SomeClass.SomeMethod(id, name, color, quantity)).HandleServerError();
return result;
As you can see, whatever method I am calling is injected into the extension method and executed inside the try/catch.
We will be using NLog or ELMAH for logging, but that is largely irrelevant to this question.
Problem
If something goes wrong, I need to log as much information about the delegated method as possible since things like "Object reference not set to an instance of an object" is not in itself helpful.
I would like to log the class and name of the method being called as well as the parameters in the method signature along with their values. If possible, I would even like to log which line failed, and finally the actual stack trace.
I am guessing that I need to use reflection for this and maybe catch the binding flags somehow as the injected method executes but I am not entirely sure if that is the best approach or if it is even feasible.
Question
Using C#, how do I get the meta information (i.e. method name, class of origin, parameters, parameter values) about an injected/delegated method?
Thanks in advance.
It seems to me that there is a possibility for you to improve the way you are adding this logging cross-cutting concern to your application.
The main issue here is that although your solution prevents you from making any changes to SomeClass.SomeMethod (or any called method), you still need to make changes to the consuming code. In other words you are breaking the Open/closed principle, which tells us that it must be possible to make these kinds of changes without changing any existing code.
You might think I'm exaggerating, but you probably already have over a hundred calls to HandleServerError in your application, and the number of calls will only be growing. And you'll soon add even more of those 'functional decorators' to the system pretty soon. Did you ever think about doing any authorization checks, method argument validation, instrumentation, or audit trailing? And you must admit that doing new Func<T>(() => someCall).HandleServerError() just feels messy, doesn't it?
You can resolve all these problems, including the problem of your actual question, by introducing the right abstraction to the system.
First step is to promote the given method arguments into a Parameter Object:
public SomeMethodParameters
{
public int Id { get; set; }
public string Name { get; set; }
public Color Color { get; set; }
public decimal Quantity { get; set; }
public decimal Result { get; set; }
}
Instead of passing all the individual arguments into a method, we can pass them all together as one single object. What's the use of that, you may say? Read on.
Second step is to introduce a generic interface to hide the actual logic of the SomeClass.SomeMethod (or in fact any method) behind:
public interface IMethodHandler<TParameter>
{
void Handle(TParameter parameter);
}
For each (business) operation in the system, you can write an IMethodHandler<TParameter> implementation. In your case you could simply create an implementation that wraps the call to SomeClass.SomeMethod, like this:
public class SomeMethodHandler
: IMethodHandler<SomeMethodParameters>
{
void Handle(SomeMethodParameters parameter)
{
parameter.Result = SomeClass.SomeMethod(
parameter.id,
parameter.Name,
parameter.Color,
parameter.Quantity);
}
}
It might look a bit silly to do things like this, but it allows you to implement this design quickly, and move the logic of the static SomeClass.SomeMethod inside of the SomeMethodHandler.
Third step is let consumers depend on a IMethodHandler<SomeMethodParameters> interface, instead of letting them depend on some static method in the system (in your case again the SomeClass.SomeMethod). Think for a moment what the benefits are of depending on such abstraction.
One interesting result of this is that it makes it much easier to unit test the consumer. But perhaps you're not interested in unit testing. But you are interested in loosely coupling. When consumers depend on such abstraction instead of a real implementation (especially static methods), you can do all kinds of crazy things, such as adding cross-cutting concerns such as logging.
A nice way to do this is to wrap IMethodHandler<T> implementations with a decorator. Here is a decorator for your use case:
public class LoggingMethodHandlerDecorator<T>
: IMethodHandler<T>
{
private readonly IMethodHandler<T> handler;
public LoggingMethodHandlerDecorator(
IMethodHandler<T> handler)
{
this.handler = handler;
}
public void Handle(T parameters)
{
try
{
this.handler.Handle(parameters);
}
catch (Exception ex)
{
//******************************
//Code for logging will go here.
//******************************
ErrorHandlers.ThrowServerErrorException(ex);
throw;
}
}
}
See how the Handle method of this decorator contains the code of your original HandleServerError<T> method? It's in fact not that much different from what you were already doing, since the HandleServerError 'decorated' (or 'extended') the behavior of the original method with new behavior. But instead of using method calls now, we're using objects.
The nice thing about all this is, is that this single generic LoggingMethodHandlerDecorator<T> can be wrapped around every single IMethodHandler<T> implementation and can be used by every consumer. This way we can add cross-cutting concerns such as logging, etc, without both the consumer and the method to know about this. This is the Open/closed principle.
But there is something else really nice about this. Your initial question was about how to get the information about the method name and the parameters. Well, all this information is easily available now, because we've wrapped all arguments in an object instead of calling some custom method wrapped inside a Func delegate. We could implement the catch clause like this:
string messageInfo = string.Format("<{0}>{1}</{0}>",
parameters.GetType().Name, string.Join("",
from property in parameters.GetType().GetProperties()
where property.CanRead
select string.Format("<{0}>{1}</{0}>",
property.Name, property.GetValue(parameters, null)));
This serializes the name of the TParameter object with its values to an XML format. Or you can of course use .NET’s XmlSerializer to serialize the object to XML or use any other serialization you need. All the information if available in the metadata, which is quite nice. When you give the parameter object a good and unique name, it allows you to identify it in the log file right away. And together with the actual parameters and perhaps some context information (such as datetime, current user, etc) you will have all the information you need to fix a bug.
There is one difference between this LoggingMethodHandlerDecorator<T> and your original HandleServerError<T>, and that is the last throw statement. Your implementation implements some sort of ON ERROR RESUME NEXT which might not be the best thing to do. Is it actually safe to continue (and return the default value) when the method failed? In my experience it usually isn't, and continuing at this point, might make the developer writing the consuming class think that everything works as expected, or might even make the user of the application think that everything worked out as expected (that his changes were saved for instance, while in fact they weren't). There's usually not much you can do about this, and wrapping everything in catch statements only makes it worse, although I can imagine that you want to log this information. Don’t be fooled by user requirements such as “the application must always work” or “we don’t want to see any error pages”. Implementing those requirements by suppressing all errors will not help and will not fix the root cause. But nonetheless, if you really need to catch-and-continue, just remove the throw statement`, and you'll be back at the original behavior.
If you want to read more about this way of designing your system: start here.
You can simply access its Method and Target properties as it's basically any other delegate.
Just use func.Method and func.Target.
In our application data tier we completely rely on stored procedures and web services for Data exchange. We use code like below in loads of pages to execute stored procedures
switch(requesttype)
{
case "GetEmployees":
switch (crud_type)
{
case "read":
Execute Stored Procedure 'A'
break;
}
break;
}
we are looking for ways to remove above code(which is inside class files) to some form of configuration file
We are looking for file storage format that are extremely fast to retrieve(read,parse etc) and save(write,modify etc)
We could implement a security layer above it
Achieve this without much fuss and major changes to existing code.
I think I got ahead of myself. You can't replace code with configuration because the code will do something while a configuration would simply tell the code what or how to do something (unless the configuration itself contains code in which case you've got a paradox). If you want to apply configurability to your code, you'll first need to make it more general/generic (your switch statements indicate that it is not general now). My approach to doing this is described in my original answer (below). It doesn't provide configurability on its own, but could be made to do so (I've done it fairly simply). The code is based on your original question so please readjust your eyes to read it correctly.
The option I've opted for in the past has been to use a factory (whether housed in a Singleton or passed to the function owning your code sample in the form of an IoC container.
Very high level implementation of my approach is basically to define a custom attribute which contains a property that indicates when your type is useful. Something like:
public class DbOperationAttribute : Attribute
{
public string Operation { get; set; }
}
And a common interface to provide the API needed for your code to be run. Something like:
public interface IDoSomethingSpecial
{
bool Execute(SomeExecutionContext context);
}
And then you decorate specific classes with the attribute and implement the interface to indicate that they are appropriate for each action:
[DbOperation(Operation = "Read")]
public class DBReadOperation : IDoSomethingUseful
{
// Our implementation of the `IDoSomethingUseful` interface
public bool Execute(SomeExecutionContext context)
{
// Do something useful in here
}
}
At some point in your program you will need to be able to discover which types are appropriate for which actions. I do this with reflection, though it could just as easily be done with configuration (which would defeat the point of the attribute). Several IoC containers provide similar discoverability attributes, though using someone else's you'll be left doing things their way (typically).
Once you've discovered which types are appropriate for which actions, you can use something like:
IDoSomethingUseful someAction = myCollectionOfUsefulThings(requesttype);
someAction.Execute(someInstanceOfOurContextType);
Based on this design I would lean towards just using the App.Config/Web.Config to store your configuration. It'll generally be there anyway; may as well use it for your purposes as well.
I'd like to get some feedback on what people think of the following class construction techniques.
If I'm in a situation where I have the choice of using either of the following:
Initialise an object completely in the constructor,
Initialise an object by way of it's public properties after the instance has been created.
[removed blogspam]
Wherever possible (and appropriate), create object instances in a usable state. (so No. 1)
I agree with Mitch, but sometimes there's more to it.
A Factory approach can make your code cleaner, easier to use and maintain. In some ways they aren't much more than glorified constructors but they do give you extra flexibility.
The factory methods can be given names that match their case of use.
Callers only need to supply the parameters required. Admittedly you can also do this for 'normal' constructors but it's clearer to the caller why they should use a given constructor if it also has an appropriate name.
Moving all complex code out of the constructors makes your code easier to maintain.
Using a Full blown Factory (one that returns an abstract class / interface) gives you some abstraction from the concrete class itself.
Examples:
// Typlical constructor
public Page(pageId, title, url, keywords, content, tags, lastModified, lastModifiedBy)
{
// All values are set via the constructor.
//...
}
Factory methods:
public static Page PageByID(pageId)
{
// All properties are set internally here
//(directly or delegated as appropriate).
//...
}
public static Page NewPage(title, url)
{
// All properties not passed in are given
// appropriate default values.
//...
}
public static Page Page404()
{
// All properties are given
// appropriate default values.
//...
}
As Mitch said, normally you'd create an object through a constructor that would at least put it in a stable state. You can use public properties later to set non-critical properties of the object.
However, sometimes you don't really have a choice. A framework might require a default constructor (without parameters). In that case you'll need to get the object in a stable state in another way. Using public properties is possible, but it would be easy to forget something. In these cases I'd advise creating an Initialize (or similar) method that you call directly after the object has been created. This method can then require you to fill in all the needed parameters for a stable state so you can't forget anything. The difference is that you can't really force calling this method unless you keep internal 'isInitialized' state that you check in each public member.
Edit: ah just saw the post about the factory. Yes, of course, in case of a framework requiring default constructors you could also get a factory back and call the methods on that.
I'm looking for a list of reasonable use cases of putting attributes in a parameter.
I can think of some good cases for attributes in a method, but can't seem to see a good usage of a parameter attribute. Please, enlighten me.
And what about attributes on the return type of a method?
A specific case where they are used is in PInvoke. Parameters in PInvoke signatures can be optionally decorated with additional information through the use of attributes so that PInvoke marshalling of individual arguments can be either explicitly specified or have the default marshalling behaviour overriden, e.g.:
[DllImport("yay.dll")]
public static extern int Bling([MarshalAs(UnmanagedType.LPStr)] string woo);
This overrides the default marshalling behaviour for the string argument "woo".
For example, in Vici MVC, a .NET MVC framework, the parameters of a controller's action method can be "mapped" to a parameter with a different name. This is how it's done in in Vici MVC:
public void ActionMethod([Parameter("user")] int userId)
{
}
This will map the parameter "user" from the query string to the parameter userId.
That's just a simple example on how you can use attributes for parameters.
When using reflection, you might want some metadata associated with a property, for example, if you were to perform some code generation based on the properties in a class.
I would say that this question is a little open ended, there will be a time sooner or later that a need will arise and you will be thankful that the language supports it.
In Boo you can add macro attributes. Such as:
def Foo([required]p):
pass
This tells the compiler to transform the Foo method into this:
def Foo(p):
raise ArgumentNullException("p") if p is null
Slightly different than the static examples but interesting nonetheless.
As others have shown, what a thing is good for can be answered by what other people do with it. E.g.in MEF you can use it on the parameter of a constructor to specify that you want to import a dependency with a certain name:
public class Foo {
[ImportingConstructor]
public Foo([Import("main")] Bar bar) {
...
}
}