I don't understand why JSR 303 (bean validation) is for the getter methods and not setter? Isn't it more logical to put it under setter method since that is the entry point into a field and validation should be checked prior to that?
Annotating getters doesn't mean that validation is performed when a getter is invoked. It is just used to identify the property to which a constraint shall apply.
The big advantage of putting constraints on (usually public) getters instead on (typically private) fields is that the constraints are part of the type's public API that way. They will even be added to the generated JavaDoc. A user of a type knows that way which constraints apply to it without looking into its internal implementation.
Another advantage of annotating getters is that constraints can be put at methods on base classes or interfaces and also apply for any sub-types/implementations.
Its a very good question and something that I have never paid attention to. But I think I know the answer ( and also why I never got this question myself).
If you are looking at this, from the point of view that, the annotation defines where the validation will happen, then putting it on getter does not make sense. ( why not validate while storing the value itself..). But this is not how it works...
The programmer needs to tell the validation framework, which properties needs to be validated. So you can put the annotation directly on the attribute (which I prefer) or you can put it on the getter. Both of them signify read operation. The Framework needs to read all the attributes of your class, that will have to be validated. So in this case, putting on setter makes no sense at all.. The key to understand is the perspective...
I hope it makes sense.
Consider this code:
public class BeanValidation {
private int nameSetCount = 0;
private int nameGetCount = 0;
private String name;
public String getName() {
this.nameGetCount++;
return name;
}
public void setName(String name) {
this.nameSetCount++;
this.name = name;
}
}
Put annotation over private String name;
Annotation identifies field easily just looking at the field.
Put annotation over public String getName()
Annotation identifies field easily just looking at the returned field.
Put annotation over public void setName(String name)
Annotation can not identify field looking at the modified field because there can be more than one.
Bean Validation is called that way for a reason. It is applied to an initialized bean. So, first off, you initialize it with everything you have, then you pass it(or it is passed explicitly) to the Bean Validation implementation, which will rely on the validation annotations when accessing the fields.
In case of Spring MVC validation handling starts at:
result = execVal.validateParameters(
invocation.getThis(), methodToValidate, invocation.getArguments(), groups);
inside MethodValidationInterceptor. From here on, it's passed to validation implementation, in most cases Hibernate.
invocation.getArguments() will contain all the method arguments already initialized with the given values, regardless of validation annotations.
Related
I ran into the following SpringMVC issue: there is a domain object which uses a certain Address sub-object, but the getters/setters have to be tweaked to use a different Address object via conversion. This is an architectural requirement.
public class DomainObj {
protected DomainObj.Address address;
public anotherpackage.new.Address getAddress()
{
return convertFrom(address);
}
public void setAddress (anotherpackage.new.Address value)
{
this.address = convertTo(value);
}
}
// Internal Address object, old, #1
public static class Address {
protected String street1;
protected String street2;
// etc., getters/setters
}
Now, in the JSP, I bind an Input Text Field to the new Address object (the result of conversions) that's what we have to deal with. In this new 2nd Address object (anotherpackage.new.Address), there is a field e.g. "addressLine1", which is different from the old object's "Street1":
<form:input path="topObject.address.addressLine1" />
My problem is that the setter, setAddress(), never gets called in this case for binding (verified in the Debugger). Any solutions to this?
Your options are:
a) do not bind directly to the business object
b) configure a binder to do the conversion to your domain object
Discussion:
Usually in enterprise class software we don't want to bind directly to the business objects -- which are usually entities (in the context of jpa). This is because session handling is a bee-otch. Usually we code against DTOs, and when one is received from the front-end we read the appropriate object from the repository (ORM) layer, update it, and save it back again (I've only described updates because they're the hardest, but a similar model works for everything).
However, spring mvc binders offer a way of binding anything to anything. They're a bit complicated and it'll take too long to explain here, but the docs are in the spring documentation and you want to be looing at converters and a conversion service. There are SO Q/A's on this topic, for example...
Why not getters? And how it combined with encapsulation principe? Does it safe?
Upd:
Yes, I'm about Request. Safety: I mean that anybody in code (by using listener) can do $request->attributes = null;
If you are talking about the Request and Response objects, there was a discussion about this on the Symfony developers mailing list a few days ago. I invite you to take a look at it here.
Why not getters? Not sure if there is a definitive answer to this but I think it is a decision based on personal tastes mainly.
Does it break encapsulation? Not really in my opinion for this particular case. My reasoning is that for now, no special logic is performed on the various objects that are public right now. So in the end, you would end up retrieving the object via a getter and read or modify it directly. There is not much difference with retrieving the object using a public property.
// With Getters
$parameterBag = $request->getQuery();
$parameterBag->get('key');
// With Public Properties
$parameterBag = $request->query;
$parameterBag->get('key');
Encapsulation should be enforced when you need to be sure that a property has a particular value or format. For example, say you have a class with a cost property and this property should never be negative. So if the cost property was public, it could be possible to set it to a negative value by doing something like $receipt->cost = -1;. However, if you make it private and the user of the class is only able to set it via a setter, then you could ensure that the cost is never below 0 by doing some special validation in the setter code.
In our case, we are talking about a collection object, a ParameterBag object to be precise. I don't think there are special requirements on this object but I could be wrong. So for me, it is correct to have access to those properties via public properties.
The main argument I could see in favor of the getters is that it would be more consistent with the other parts of the framework where getters are used. However, the getters could co-exist with the public properties.
To conclude, I think it is safe for this particular case. Public properties should be used only in special cases where it seems to be beneficial and where it is correct to do so.
Do you mean the Request object? Or what properties are you thinking of?
If you're worried about safety, then take a look at the Security component, use Test-Driven-Development, use tested libraries (don't invent your own authentication, cryptography and related solutions) and do code reviews.
What's the point to encapsulate what already's been encapsulated? I mean - each of this properties is a parameterBag instance with it's encapsulation.
Why is the FxCop rule CA1061 a bad idea?
The docs state that this rule should not be suppressed. If I have class like so:
public class Set<T>
{ List<T> m_backingList;
public bool Contains(T value)
{
return m_backingList.Contains(value);
}
}
then I add a specific implementation like this:
public class CaseInsensitiveSet : Set<String>
{
public bool Contains(object value)
{
string stringValue = value as string;
if (stringValue == null)
return false;
return base.Contains(stringValue);
}
}
the FxCop complains, but I'm not certain why this is such a bad idea. Is there some problem I don't see with this implementation?
The rule states why you're getting the message:
A method in a base type is hidden by
an identically named method in a
derived type when the parameter
signature of the derived method
differs only by types that are more
weakly derived than the corresponding
types in the parameter signature of
the base method.
In your child class, the Contains method takes an object which is more weakly typed than string and therefore hides the parent.
The reason you're getting the warning from FxCop is that this might not be an intentional design choice (since you're not overriding anything or using the new keyword).
Even if it is an intentional design choice, I would argue that it's not necessarily a good one. If you already know that the collection is going to contain strings and nothing else, why would you provide a Contains method that takes anything other than a string? It may appear that you're adding flexibility into the design but, in the end, you're really only going to confuse other developers.
There are also other naming options instead of calling the method Contains which wouldn't hide (intentionally or not) the base Contains method.
Ask yourself: do I want the users to be able to call the base class method on an instance of the derived class.
If the answer is yes: don't hide the base method, as this will make it more cumbersome to use it.
If the answer is no: don't derive from this class, or else they can still access the base method by casting the object to the base class.
http://msdn.microsoft.com/en-us/library/ms182143(VS.80).aspx
A method in a base type is hidden by
an identically named method in a
derived type when the parameter
signature of the derived method
differs only by types that are more
weakly derived than the corresponding
types in the parameter signature of
the base method.
EDIT
Basically you're hiding the base method (public bool Contains in Set), which will never now be run in preference to the derived method. But the derived method is more weakly defined than the base method so there are situations when the base method is the preferable method.
I'm attempting to create a generic controller, ie:
public class MyController<T> : Controller where T : SomeType
{ ... }
However, when I try to use it, I'm running into this error everywhere...
Controller name must end in 'Controller'
So, my question, Is it possible to make a generic controller in asp.net mvc?
Thanks!
If I understand you properly, what you are trying to do, is route all requests for a given Model through a generic controller of type T.
You would like the T to vary based on the Model requested.
You would like /Product/Index to trigger MyController<Product>.Index()
This can be accomplished by writing your own IControllerFactory and implementing the CreateController method like this:
public IController CreateController(RequestContext requestContext, string controllerName)
{
Type controllerType = Type.GetType("MyController")
.MakeGenericType(Type.GetType(controllerName));
return Activator.CreateInstance(controllerType) as IController;
}
Yes you can, it's fine and I've used them lots myself.
What you need to ensure is that when you inherit from MyController you still end the type name with controller:
public class FooController : MyController<Foo>
{
...
}
The default controller factory uses "convention" around controller names when it's trying to find a controller to dispatch the request to. You could override this lookup functionality if you wanted, which could then allow your generic controller to work.
This MSDN article...
http://msdn.microsoft.com/en-us/magazine/dd695917.aspx
... has a good writeup of what's going on.
This is a duplicate of asp.net mvc generic controller which actually contains the correct answer. Jeff Fritz's answer is absolutely not correct. Creating your own IControllerFactory will not get past the limitation in ExpressionHelper.GetRouteValuesFromExpression which is generating the error you are seeing. Implementing your own IControllerFactory will still leave you with errors whenever you call RedirectToAction, BuildUrlFromExpression, ActionLink, RenderAction, BeginForm, any any methods that call those.
What is interesting to me, is that Microsoft's "restriction by convention" is already enforced by the constraint "where TController : Controller" that is placed upon the type in the ExpressionHelper.GetRouteValuesFromExpression method. No generic will ever satisfy the convention validation:
string controllerName = typeof(TController).Name;
if (!controllerName.EndsWith("Controller", StringComparison.OrdinalIgnoreCase)) {
throw new ArgumentException(MvcResources.ExpressionHelper_TargetMustEndInController, "action");
}
unless it is inherited by a class ending in "Controller" because typeof(AnyGeneric).Name will never end with "Controller".
If i was you, i'd get the MVC source and create a test MVC project with the source code so you can examine where the exception is generated and see what you can do about your generic idea and the enforced "*controller" naming convention.
What options are there for serialization when returning instances of custom classes from a WebService?
We have some classes with a number of child collection class properties as well as other properties that may or may not be set depending on usage. These objects are returned from an ASP.NET .asmx WebService decorated with the ScriptService attribute, so are serialized via JSON serialization when returned by the various WebMethods.
The problem is that the out of the box serialization returns all public properties, regardless of whether or not they are used, as well as returning class name and other information in a more verbose manner than would be desired if you wanted to limit the amount of traffic.
Currently, for the classes being returned we have added custom javascript converters that handle the JSON serializtion, and added them to the web.config as below:
<system.web.extensions>
<scripting>
<webServices>
<jsonSerialization>
<converters>
<add name="CustomClassConverter" type="Namespace.CustomClassConverter" />
</converters>
</jsonSerialization>
</webServices>
</scripting>
</system.web.extensions>
But this requires a custom converter for each class. Is there any other way to change the out of the box JSON serialization, either through extending the service, creating a custom serializer or the like?
Follow Up
#marxidad:
We are using the DataContractJsonSerializer class in other applications, however I have been unable to figure out how to apply it to these services. Here's an example of how the services are set-up:
[ScriptService]
public class MyService : System.Web.Services.WebService
{
[WebMethod]
public CustomClass GetCustomClassMethod
{
return new customClass();
}
}
The WebMethods are called by javascript and return data serialized in JSON. The only method we have been able to change the serialization is to use the javascript converters as referenced above?
Is there a way to tell the WebService to use a custom DataContractJsonSerializer? Whether it be by web.config configuration, decorating the service with attributes, etc.?
Update
Well, we couldn't find any way to switch the out of the box JavaScriptSerializer except for creating individual JavaScriptConverters as above.
What we did on that end to prevent having to create a separate converter was create a generic JavaScriptConverter. We added an empty interface to the classes we wanted handled and the SupportedTypes which is called on web-service start-up uses reflection to find any types that implement the interface kind of like this:
public override IEnumerable<Type> SupportedTypes
{
get
{
foreach (Assembly assembly in AppDomain.CurrentDomain.GetAssemblies())
{
AssemblyBuilder dynamicAssemblyCheck = assembly as AssemblyBuilder;
if (dynamicAssemblyCheck == null)
{
foreach (Type type in assembly.GetExportedTypes())
{
if (typeof(ICustomClass).IsAssignableFrom(type))
{
yield return type;
}
}
}
}
}
}
The actual implementation is a bit different so that the type are cached, and we will likely refactor it to use custom attributes rather than an empty interface.
However with this, we ran into a slightly different problem when dealing with custom collections. These typically just extend a generic list, but the custom classes are used instead of the List<> itself because there is generally custom logic, sorting etc. in the collection classes.
The problem is that the Serialize method for a JavaScriptConverter returns a dictionary which is serialized into JSON as name value pairs with the associated type, whereas a list is returned as an array. So the collection classes could not be easily serialized using the converter. The solution for this was to just not include those types in the converter's SupportedTypes and they serialize perfectly as lists.
So, serialization works, but when you try to pass these objects the other way as a parameter for a web service call, the deserialization breaks, because they can't be the input is treated as a list of string/object dictionaries, which can't be converted to a list of whatever custom class the collection contains. The only way we could find to deal with this is to create a generic class that is a list of string/object dictionaries which then converts the list to the appropriate custom collection class, and then changing any web service parameters to use the generic class instead.
I'm sure there are tons of issues and violations of "best practices" here, but it gets the job done for us without creating a ton of custom converter classes.
If you don't use code-generated classes, you can decorate your properties with the ScriptIgnoreAttribute to tell the serializer to ignore certain properties. Xml serialization has a similar attribute.
Of course, you cannot use this approach if you want to return some properties of a class on one service method call and different properties of the same class on a different service method call. If you want to do that, return an anonymous type in the service method.
[WebMethod]
[ScriptMethod]
public object GimmieData()
{
var dalEntity = dal.GimmieEntity(); //However yours works...
return new
{
id = dalEntity.Id,
description = dalEntity.Desc
};
}
The serializer could care less about the type of the object you send to it, since it just turns it into text anyway.
I also believe that you could implement ISerializable on your data entity (as a partial class if you have code-gen'd data entities) to gain fine-grained control over the serialization process, but I haven't tried it.
I know this thread has been quiet for a while, but I thought I'd offer that if you override the SupportedTypes property of JavaScriptConverter in you custom converter, you can add the types that should use the converter. This could go into a config file if necessary. That way you wouldn't need a custom converter for each class.
I tried to create a generic converter but couldn't figure out how to identify it in the web.config. Would love to find out if anyone else has managed it.
I got the idea when trying to solve the above issue and stumbled on Nick Berardi's "Creating a more accurate JSON .NET Serializer" (google it).
Worked for me:)
Thanks to all.
If you're using .NET 3.x (or can), a WCF service is going to be your best bet.
You can selectively control which properties are serialized to the client with the [DataMember] attribute. WCF also allows more fine-grained control over the JSON serialization and deserialization, if you desire it.
This is a good example to get started: http://blogs.msdn.com/kaevans/archive/2007/09/04/using-wcf-json-linq-and-ajax-passing-complex-types-to-wcf-services-with-json-encoding.aspx
You can use the System.Runtime.Serialization.Json.DataContractJsonSerializer class in the System.ServiceModel.Web.dll assembly.
Don't quote me on this working for certain, but I believe this is what you are looking for.
[WebMethod]
[ScriptMethod(ResponseFormat = ResponseFormat.Json)]
public XmlDocument GetXmlDocument()
{
XmlDocument xmlDoc = new XmlDocument();
xmlDoc.LoadXml(_xmlString);
return xmlDoc;
}