service validation in different layers? RRS feed

  • Question

  • User1610691276 posted

    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?

    Monday, October 29, 2012 12:13 AM

All replies

  • User824124681 posted

    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 )

    Monday, October 29, 2012 5:57 AM
  • User1100692814 posted


    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;
                    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
                            // Send registration email
                            _emailSender.SendRegistrationInfo(userName, password, email);
                            isSuccess = true;
                            Log.Info("User registered: {0}", user.UserName);
                            Log.Warning("User validation error.");
                catch (Exception e)
                return isSuccess;

    Hope this helps.


    Monday, October 29, 2012 6:01 AM
  • User1610691276 posted

    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....

    Monday, October 29, 2012 1:35 PM
  • User-210056564 posted

    Edited: erroneous content removed

    Monday, October 29, 2012 10:19 PM
  • User1610691276 posted

    dharm - my question is about input validation not security

    Tuesday, October 30, 2012 11:48 AM
  • User-869952975 posted

    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.

    Friday, November 2, 2012 10:31 AM