Hello - How would you go about implementing validation in the following architecture where technically validation could be implemented in multiple layers?:
* WCF service calls BLL
* BLL calls DAL
* DAL calls stored proc
* stored proc gets/sets data in database table
Personally, when I implement a service I think of SOA as the intended use of the functionality. It is the quickest implementation of validation and seems to provide the most bang for the buck. However, if I'm working with someone who doesn't have any real
SOA experience but has done a lot of database work then he may be database centric and argue that validation should be implemented at the stored proc and database level in case anyone tries to call the stored proc or database directly.
I can understand that perspective as well and it raises a question - how much validation should be implemented throughout the layers? Are there any existing architecture patterns that define different models or implementation levels describing which model
should be used or which model should be used in different scenarios?
What kind of validation are you talking abuot? Is it about validation or something called authentication?
As I know, no one can call your store proc directly without exposing the name of your proc, SQL authentications. You must be using Proxy and your end user is restricted to that. What you exposed using your proxy is/should be limited.
For validation point it should be done at database layer before inserting/updating/deleting or querying. It depends on the business scenario. Instead of making 2-3 calls to the server before a DML operation, why not to write all in one proc where you do
validations before your DML. You can define your message return type and can get it at UI lavel. Offcourse you can implement some validation at UI so that bad data can be avoided to post database. So at both end validation is required.
Your mentioned layers are very good to implement and I see no deficiency in it (atleast at my level of understanding )
But, be careful service contracts that contain detailed validation constraints become more easily invalidated when the rules behind those constraints change. This is a problem, we had recetnyl at work. The solution was to make a more granular
validation logic, and rules that can be abstracted away from the service contract, thereby decreasing constraint granularity and increasing the contract's potential longevity.
We therefore went for a more abstracted validation logic which moved the validation to the underlying service logic. We look at our Service layer as our BLL or in your case an extension of your BLL.
Instead of making 2-3 calls to the server before a DML operation, why not to write all in one proc where you do validations before your DML.
@anil - one could also argue that data could be entered directly into the database which would bypass the stored procedure. So one could argue that database/table-level validation should also be implemented.
Here's one use case. How would you implement the following validation constraint?: "A user's email address should be unique"
The simplest way to implement this constraint from a technical perspective would be to add a unique constraint for email on the User table. But then if we just do that are we saying that it's acceptable for validation to be implemented in different layers
for different types of validation scenarios?
Or should validation be implemented at the database, stored proc and service level as completely and consistently as possible?
There is definitely a design decision to made here and I was curious if Microsoft has written about this or if there have been other discussions about this....
Validation should be implemented at layer wise based on data flow .let say if it is user input validation then it should be done before service call, business rules related and DB related verfication should be done at BLL and DAL respectively. but putting
all at one place is not an ideal approach because doing rollback due to validation fail at DAL after crossing all layers may be costly (response time) and inefficent process.
dotnetterAMG...
Member
234 Points
510 Posts
service validation in different layers?
Oct 29, 2012 04:13 AM|LINK
Hello - How would you go about implementing validation in the following architecture where technically validation could be implemented in multiple layers?:
* WCF service calls BLL
* BLL calls DAL
* DAL calls stored proc
* stored proc gets/sets data in database table
Personally, when I implement a service I think of SOA as the intended use of the functionality. It is the quickest implementation of validation and seems to provide the most bang for the buck. However, if I'm working with someone who doesn't have any real SOA experience but has done a lot of database work then he may be database centric and argue that validation should be implemented at the stored proc and database level in case anyone tries to call the stored proc or database directly.
I can understand that perspective as well and it raises a question - how much validation should be implemented throughout the layers? Are there any existing architecture patterns that define different models or implementation levels describing which model should be used or which model should be used in different scenarios?
anil.india
Contributor
2613 Points
453 Posts
Re: service validation in different layers?
Oct 29, 2012 09:57 AM|LINK
What kind of validation are you talking abuot? Is it about validation or something called authentication?
As I know, no one can call your store proc directly without exposing the name of your proc, SQL authentications. You must be using Proxy and your end user is restricted to that. What you exposed using your proxy is/should be limited.
For validation point it should be done at database layer before inserting/updating/deleting or querying. It depends on the business scenario. Instead of making 2-3 calls to the server before a DML operation, why not to write all in one proc where you do validations before your DML. You can define your message return type and can get it at UI lavel. Offcourse you can implement some validation at UI so that bad data can be avoided to post database. So at both end validation is required.
Your mentioned layers are very good to implement and I see no deficiency in it (atleast at my level of understanding )
codepattern.net/blog ||@AnilAwadh
Dave_Winches...
Contributor
3051 Points
716 Posts
Re: service validation in different layers?
Oct 29, 2012 10:01 AM|LINK
Hi
Personally, I would not place any validation logic deep within the DAL. You need to look at what validation requirements you need to meet.
In terms of data validation, you could use Data Annotation Attributes (http://msdn.microsoft.com/en-us/library/ee256141(v=vs.98).aspx) for an example.
But, be careful service contracts that contain detailed validation constraints become more easily invalidated when the rules behind those constraints change. This is a problem, we had recetnyl at work. The solution was to make a more granular validation logic, and rules that can be abstracted away from the service contract, thereby decreasing constraint granularity and increasing the contract's potential longevity.
We therefore went for a more abstracted validation logic which moved the validation to the underlying service logic. We look at our Service layer as our BLL or in your case an extension of your BLL.
This is an example from our Security Service:
public virtual bool Create(string userName, string password, string email) { bool isSuccess = false; try { using (IUnitOfWork unitOfWork = UnitOfWork.Begin()) { IUser user = _factory.CreateUser(userName, password, email); // Validate the user ValidationResult results = _validator.Validate(user); // Check if validation passed if (results.IsValid) { // Add user _userRepository.Add(user); unitOfWork.Commit(); // Send registration email _emailSender.SendRegistrationInfo(userName, password, email); isSuccess = true; Log.Info("User registered: {0}", user.UserName); } else { Log.Warning("User validation error."); } } } catch (Exception e) { Log.Exception(e); } return isSuccess; }Hope this helps.
/D
Please mark as ANSWER if this is the solution.
dotnetterAMG...
Member
234 Points
510 Posts
Re: service validation in different layers?
Oct 29, 2012 05:35 PM|LINK
@anil - one could also argue that data could be entered directly into the database which would bypass the stored procedure. So one could argue that database/table-level validation should also be implemented.
Here's one use case. How would you implement the following validation constraint?: "A user's email address should be unique"
The simplest way to implement this constraint from a technical perspective would be to add a unique constraint for email on the User table. But then if we just do that are we saying that it's acceptable for validation to be implemented in different layers for different types of validation scenarios?
Or should validation be implemented at the database, stored proc and service level as completely and consistently as possible?
There is definitely a design decision to made here and I was curious if Microsoft has written about this or if there have been other discussions about this....
dharmbhav
Member
18 Points
5 Posts
Re: service validation in different layers?
Oct 30, 2012 02:19 AM|LINK
Edited: erroneous content removed
dotnetterAMG...
Member
234 Points
510 Posts
Re: service validation in different layers?
Oct 30, 2012 03:48 PM|LINK
dharm - my question is about input validation not security
chandruasp
Member
72 Points
24 Posts
Re: service validation in different layers?
Nov 02, 2012 02:31 PM|LINK
Validation should be implemented at layer wise based on data flow .let say if it is user input validation then it should be done before service call, business rules related and DB related verfication should be done at BLL and DAL respectively. but putting all at one place is not an ideal approach because doing rollback due to validation fail at DAL after crossing all layers may be costly (response time) and inefficent process.