Our UI exposes user input as strings. All of them, including dates and numbers, are coming as strings. The question is: is it better to convert these to the appropriate type (datetime, int, etc) in the UI (and then pass converted var to the BLL methods), or in the BLL itself?
Input validation and conversion should be done on the UI layer.
Not only is this so your business layer is dealing with typed data, but also so that you can easily throw UI error messages if they enter the wrong type or if the value is outside your range*.
*Some frameworks have their own validation logic for this sort of thing... ASP.NET being the first I can think of.
UI type conversion should be done in the UI layer, not the BL layer. This decouples the UI from the BL.
I prefer to do type casting in the UI and have the BLL expect the proper datatype.
Related
During her brilliant presentation about scaling GraphQL, Leanne Shapton showed some best practices.
One of the most attractive for me was the custom scalar type for HTML structure. On the video it's [10:16]
She proposed using the custom HTML instead of simple String.
I wish you could show your implementation of this scalar or how do you handle these cases as I'm using only String for any HTML structure which doesn't seem to be a perfect way.
I'm asking not for creating scalar types or general information what is it scalar type and so on. Wondering if someone else has HTML handling already and does someone has any working solutions
At a pure GraphQL level, the only thing you can (and must) do is include a definition for the scalar type:
scalar HTML
Once you done that, you can use it as a type as shown in the slide you cite. In queries and results it will appear as some sort of scalar (string or numeric) value.
Different server and client libraries have different ways of dealing with this; there may be a uniform way to map a specific GraphQL scalar type to a native-language object. In graphql-js, a GraphQLScalarType object takes parseValue and serialize functions to convert between the two representations, for example. If you're just using a custom scalar type as a tagged string these can be very simple functions.
I am using Spring MVC for my presentation layer, and am also using Spring for my Service and DAO layers. Normally I would format data in the View layer of MVC (in my case JSPs), but what if the data that is retrieved from the database is not in a standardized format?
For instance, I am pulling phone numbers from one of my company's databases, but they could potentially be in any format (111)-555-1234 or 1115551234, etc. This seems like it would be too much functionality and processing to place in the JSP/View layer. I would prefer to put all of the numbers in the same format somewhere else and then re-format on the View. Where should I format in this situation - Service layer? DAO?
This would also allow me to take advantage of libraries that I could not potentially call from a JSP (or that would not make sense to call from a JSP).
Thanks!
I would have the DAO query methods remove the formatting characters from the phone numbers, and have the presentation layer give them a consistent format (probably in JSP tags). I am not a fan of putting business logic in DAOs, but this seems extremely data-related.
(Actually if the formatting code first removes any pre-existing formatting before doing its own formatting, you might be able to get by without removing formatting characters anywhere else. I just like having things in a canonical form.)
As an alternative to putting the formatting-char-removal in the DAO, if you are using Hibernate then you can create custom user types that remove or insert formatting characters from the phone number attributes.
I generally do formatting, when I map the Model to Value object (VO or whatever you want to call them), mostly in the presentation layer (or i put a layer in between the presentation and service layer, If I have too many things to do). This brings consistency in the format across the application, if that is what you want.
When i want the name to be in camelcase, I do this
BeanUtils.copyProperties(userAccount, userAccountVO, ignoreProperties);
userAccountVO.setName(StringUtilities.convertToCamelCase(userAccountVO.getName()));
I would need some clarification regarding the difference between Spring MVC formatters and converters.
My understanding of the main difference between them is that the formatter works on data that is going to be displayed to the end user such as a date, SSN or credit card number whereas the converter works on data hidden behind form controls such as the value attribute of an select's option.
Am I right or wrong? Can someone please provide advice and/or samples in order to better explain the difference between the two.
Converters are used to convert one Java type to another Java type. For example, from Long to java.util.Date or from Integer to Color or from String to Date. It can be used in the web tier or any other tier that needs conversion service.
Formatters are used to convert String to another Java type and back. So, one type must be String. You cannot, for example, write a formatter that converts a Long to a Date. Examples of formatters are DateFormatter, for parsing String to java.util.Date and formatting a Date. In addition, formatters' messages can be localized.
Conclusion: formatters are suitable in the web environment, such as a Spring MVC application.
Converter components are used for converting one type to another type and also to provide a cleaner separation by forcing to place all such conversion related code in one single place.
Spring already supports built-in converters for the commonly used types and the framework is extensible enough for writing custom converters as well.
Spring Formatters come into picture to format the data according to the display where it is rendered. Examples may include formatting date/timestamp values according to locales etc.
I have been reading about specifications lately and I am really keen on using them. However, I am afraid to overdo it.
For example, if I have a User entity with a phone number property, do I need to put the phone number specification test in the setter, or is the validation logic in the setter enough?
Thanks,
Phil
UPDATE:
For more context:
I think I would like the validation to be in the domain, and not in the presentation. I will implement the validation in presentation, but that will be more of a UI feature. The idea (i believe) is that the domain cannot be in an invalid state, nor can it rely on the presentation. I actually have a phone number Entity, and many entities have phone numbers, though I suppose this could value object, but that is another debate:)
I was just wondering if it overkill to use Specifications in Property setters. One advantage I could see is that Specifications can be shared between layers, ie the Presentation Layer, so that you can share the validation code.
As you can see, I am unsure if this is the right approach.
Much Thanks,
Phil
You might look into the notion of pre and post conditions (invariants or design by contract).
Pre conditions are things that must be true for your function to operate correctly.
Post conditions are things that will be true when your function is complete and exits normally.
"user's phone number valid" is probably a good post condition to have for your setter function. However you have 2 choices for the pre-condition: (1) make it a precondition of your setter function that whatever is passed to it is valid, or (2) make a much looser pre condition to your setter function and perform the error checking in your setter function. Option (1) essentially passes responsibility for validation to the client. Option (2) endows your User entity with the responsibility for error handling.
I think the design you choose would depend on the bigger picture for your specific application.
Here are a few links for invariants and design by contract:
http://svengrand.blogspot.com/2008/11/preconditions-postconditions-invariants.html
http://en.wikibooks.org/wiki/Computer_Programming/Design_by_Contract
In coding a traditional MVC application, what is the best practice for coding server-side form validations? Does the code belong in the controller, or the model layer? And why?
From Wikipedia:
Model-view-controller (MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC, the model represents the information (the data) of the application and the business rules used to manipulate the data; the view corresponds to elements of the user interface such as text, checkbox items, and so forth; and the controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.
Thus, model - it holds the application and the business rules.
I completely agree with Josh. However you may create a kind of validation layer between Controller and Model so that most of syntactical validations can be carried out on data before it reaches to model.
For example,
The validation layer would validate the date format, amount format, mandatory fields, etc...
So that model would purely concentrate on business validations like x amount should be greater than y amount.
My experience with MVC thus far consists of entirely rails.
Rails does it's validation 100% in the Model.
For the most part this works very well. I'd say 9 out of 10 times it's all you need.
There are some areas however where what you're submitting from a form doesn't match up with your model properly. There may be some additional filtering/rearranging or so on.
The best way to solve these situations I've found is to create faux-model objects, which basically act like Model objects but map 1-to-1 with the form data. These faux-model objects don't actually save anything, they're just a bucket for the data with validations attached.
An example of such a thing (in rails) is ActiveForm
Once the data gets into those (and is valid) it's usually a pretty simple step to transfer it directly across to your actual models.
The basic syntax check should be in the control as it translates the user input for the model. The model needs to do the real data validation.