Sunday, 18 August 2013

Application Design - Validation and efficiency

Application Design - Validation and efficiency

I have an ASP.Net application which has a lot of business rules with
regards to if an object is OK to be commited to the database.
On a basic level, a person is part of a sprint, which is part of a project.
The basic rules are:
A person is assigned to a sprint, but maybe not the full duration of a
sprint (Which has a start and end date). So, when they assign the person,
his start date and end date must be between (inclusivly) the start and end
date of a sprint.
A project can have many sprints, but none can be outside of the project
start/end dates.
My solution has a UI project, Service layer, business layer and data
access layer.
I am building in the validation now, but am not sure at what level in my
app, the calidation should occur. I don't believe it's at the UI, as then
I need to duplciate the validation rules on my ASP.Net project ... maybe
my WinForms front end...
I think it should be in the busines logic, as it has business rules. So, I
was going to make a class called "Validations", and for each of my
business objects that get stored to the database, I have a method in my
Validations called "IsObjectOK", taking in the object type I want to
validate, and returning a List of errors.
So:
public List<String> IsObjectOK(SprintDto source)
{
// Do validations, and return list of errors, or NULL if none
}
An example then of a validation rule might be:
var Project = BusinessLayer.GetProject(source.ProjectId);
// check if Start/End dates fall between Project.Start and Project.End dates
If there's an issue, add it to the error list.
This seems like a good way to go. I am looking for confirmation on my
method of handling validation, and any tips and tricks? Should I not worry
about the database hits? I mean, for a sprint, there may be around 6 or 7
'rules' I need to validate, all of which may take data from different
tables. So, that's 7 database queries (Plus the connection overhead), for
a single save. (SQL Server 2012). I think that's not a worry, as it's all
confided to the Business and data layers.

No comments:

Post a Comment