I previously asked a similar question on this topic a while back and got some good feedback, but I still have some doubts about how to proceed.
Here is the scenario...
App allows users to post and delete their comments about a video.
When a user posts a comment, the UI layer passes the comment string and the userId (guid) and when deleting passes the commentId (int) and userId (guid) to the BLL which then passes to the DAL.
At the UI layer, I assume I need to do full validation, so I make sure of the following using both client (where applicable) and server side validation:
- userId is in fact a guid
- userId exists in the user database (by calling a BLL method)
- userId is the one associated with the commentId (for delete) (by calling a BLL method)
- comment is not blank
- comment does not exceed the max length
- commentId is > 0
- commentId exists in the database (by calling a BLL method)
- videoId is > 0
- videoId exists in the database (by calling a BLL method)
After all these validations take place, I will call the BLL methods as
Save(string comment, int videoId, string userId) or Delete(int commentId, string userId)
Since the BLL could also be used as a webservice or for other pages/apps, I know I need to do validation in the BLL as well. From 开发者_运维技巧what I have learned, I am thinking I need to redo all the same validations I just did in the UI layer:
- userId is in fact a guid
- userId exists in the user database (by calling a BLL method)
- userId is the one associated with the commentId (for delete) (by calling a BLL method)
- comment is not blank
- comment does not exceed the max length
- commentId is > 0
- commentId exists in the database (by calling a BLL method)
- videoId is > 0
- videoId exists in the database (by calling a BLL method)
Is this correct? I hate to make the extra database calls unless I have to!
Now I need to call the associated DAL calls to actually make the database changes. Which of the above validations do I need to perform again in the DAL?
This app is not being sold or anything, but I want to understand the best way to handle the validation without killing performance with extra database calls that I may or may not need.
I do validation in the UI layer only for things which could be innocent user errors. Validation here is purely for the sake of usability. From your list, that would be
- comment is not blank
- comment does not exceed the max length
Fortunately, those don't require database calls.
On the backend, you need to validate everything from your list. That's the only way to truly ensure to ensure validity, security, integrity, etc.
If something passes the UI layer validations but fails backend validations, something very very wrong happened - either a malicious user or a bug in your code. If it's a bug in your code, showing validation messages to the user isn't really helpful to them. If it's a malicious user, valdiation messages are actually harmful because they make it easier for a bad guy to determine what validation checks you do and find holes. When validations fails in the backend, your app should just give the user a generic error message.
In my view, you should be validating at each level every item which you have the ability to validate. The cold war era statement of "trust but verify" applies here. Assuming that you have a well layered approach and that each layer has the likelyhood of being reused at some later point in another project, assuming that an upper layer in the future will validate the same way the original ones did is a bad assumption.
Obviously, this has the potential of adding much more validation than business logic and even repeating validations, but is probably safer.
If you are looking to save the DB calls, then I would say do them at the lowest level, but just make sure that your error handling at the upper levels is robust enough to handle a wide range of error conditions bubbling up.
I would not recommend you to do a bunch of extra checks with each chack having an own database call. How about creating a stored procedure and putting all database-checks into it. Then you can call "Class.IsDatabaseValid(string, string, Id, whatever)". So the "IsDatabaseValid"-method would be part of the BLL-validity-checks and you have a single db-call on the sp.
A rather simplistic answer I know, but as each layer represents a boundary, you cannot trust any code outside of the layer, so whilst you may have validation in your UI you should view the logic that runs in your Business layer (Domain) as being the only real validation logic.
See page 11, Business Logic, of Expert C# 2008 Business Objects.
精彩评论