Programming Forums > Application Development > Software Design and Algorithms

hoffmandirt · Apr 28th, 2006, 10:13 AM

I am curious how you guys handle domain object validation. Say for example I have an employee class. Currently I perform the validation inside the class itself. So for instance if someone sets an employee.FirstName property to an invalid length, an exception is thrown. Is it good practice to perform validation in the domain object, or should it be in the business layer?

grumpy · Apr 28th, 2006, 10:32 AM

As a general rule,I would perform validation in the domain object, as I would essentially make each object responsible for ensuring it is in a valid and usable state. That might mean throwing exceptions, or it might mean simply ignoring invalid changes. Exceptions to this general rule might include cases where one object is responsible for managing the state of another (eg X manages two other objects A and B, and enforces some relationship between them) but, even then, I tend to prefer having the individual objects responsible for their own state (eg A and B manage their own state, and X only manages the interrelationship between the pair).

Each object needs to have an interface definition (eg a set of arguments, preconditions, postconditions for each operation), and the business layer needs to respect the rules of each object's interface. It is certainly appropriate for the objects to ignore or complain bitterly (e.g. throw an exception) if the business layer doesn't obey the rules. But the "business layer" can have responsibility for validation (eg if the business layer rather than another object manages relationships between objects).

Arevos · Apr 28th, 2006, 11:04 AM

Objects should, in my opinion, be responsible for the data they receive. Objects should degrade gracefully on invalid input, throwing the appropriate exceptions and allowing the next layer up to worry about what to do about it.

However, for any non-trivial system, there should also be some kind of shared validation system. For instance:

(Toggle Plain Text)

from attributes import *
class Person(Attributes):
    name        = String(blank = False)
    age         = Integer(minimum = 0)
    phonenumber = PhoneNumber(max_length = 10)

The attributes module would hypothetically include many validation classes and methods that could be reused for different data objects.

hoffmandirt · Apr 28th, 2006, 11:13 AM

All right this makes sense. One other thing, do you guys think it is overkill to validate the length of every field to match the length specified in the database schema?

Arevos · Apr 28th, 2006, 5:54 PM

Hm. Well, presumably your database will be perfectly capable of handling inputs that are too long, though most databases seem to cut off the end, rather than raise any sort of exception. If the length of your field is some large number that you hope most users will never even get near, then you could skip length validation, so long as it's not a security risk. If the length is small, then it does make sense to validate.

Really though, length validation should take up very little code, especially if done right, so I see no reason not to do it.

grumpy · Apr 28th, 2006, 6:39 PM

In addition to what Arevos said, it depends on where you're getting data from to feed into the database and what you're doing with the data you get back from it. For example, if you're getting data from a GUI, it is arguably better to validate data (and, if necessary) pester the user to get it right before inserting it into the database. That will avoid future surprises when the data is retrieved (and you may be able to avoid any need to validate data on retrieval). However, if the database is being fed by some other system, it may be appropriate to validate the data as you retrieve it. If you really care about security and redundancy, you will always validate data you get from another system (whether a GUI or database) or send to another system. That helps ensure your component systems respect each others interfaces, and can avoid situations were corruption of data propagates.

Apr 28th, 2006, 10:13 AM	#1
hoffmandirt Hobbyist Programmer Join Date: Jul 2005 Location: PA Posts: 125 Rep Power: 4	Domain Object Validation I am curious how you guys handle domain object validation. Say for example I have an employee class. Currently I perform the validation inside the class itself. So for instance if someone sets an employee.FirstName property to an invalid length, an exception is thrown. Is it good practice to perform validation in the domain object, or should it be in the business layer?

Apr 28th, 2006, 11:04 AM	#3
Arevos Programming Guru Join Date: Aug 2005 Location: England Posts: 1,499 Rep Power: 5	Objects should, in my opinion, be responsible for the data they receive. Objects should degrade gracefully on invalid input, throwing the appropriate exceptions and allowing the next layer up to worry about what to do about it. However, for any non-trivial system, there should also be some kind of shared validation system. For instance: (Toggle Plain Text) from attributes import * class Person(Attributes): name = String(blank = False) age = Integer(minimum = 0) phonenumber = PhoneNumber(max_length = 10) from attributes import * class Person(Attributes): name = String(blank = False) age = Integer(minimum = 0) phonenumber = PhoneNumber(max_length = 10) The attributes module would hypothetically include many validation classes and methods that could be reused for different data objects.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Apr 28th, 2006, 10:32 AM	#2
grumpy Programming Guru Join Date: Jun 2005 Location: Adelaide, South Australia Posts: 1,209 Rep Power: 5	As a general rule,I would perform validation in the domain object, as I would essentially make each object responsible for ensuring it is in a valid and usable state. That might mean throwing exceptions, or it might mean simply ignoring invalid changes. Exceptions to this general rule might include cases where one object is responsible for managing the state of another (eg X manages two other objects A and B, and enforces some relationship between them) but, even then, I tend to prefer having the individual objects responsible for their own state (eg A and B manage their own state, and X only manages the interrelationship between the pair). Each object needs to have an interface definition (eg a set of arguments, preconditions, postconditions for each operation), and the business layer needs to respect the rules of each object's interface. It is certainly appropriate for the objects to ignore or complain bitterly (e.g. throw an exception) if the business layer doesn't obey the rules. But the "business layer" can have responsibility for validation (eg if the business layer rather than another object manages relationships between objects).

Apr 28th, 2006, 11:13 AM	#4
hoffmandirt Hobbyist Programmer Join Date: Jul 2005 Location: PA Posts: 125 Rep Power: 4	All right this makes sense. One other thing, do you guys think it is overkill to validate the length of every field to match the length specified in the database schema?

Apr 28th, 2006, 5:54 PM	#5
Arevos Programming Guru Join Date: Aug 2005 Location: England Posts: 1,499 Rep Power: 5	Hm. Well, presumably your database will be perfectly capable of handling inputs that are too long, though most databases seem to cut off the end, rather than raise any sort of exception. If the length of your field is some large number that you hope most users will never even get near, then you could skip length validation, so long as it's not a security risk. If the length is small, then it does make sense to validate. Really though, length validation should take up very little code, especially if done right, so I see no reason not to do it.

Apr 28th, 2006, 6:39 PM	#6
grumpy Programming Guru Join Date: Jun 2005 Location: Adelaide, South Australia Posts: 1,209 Rep Power: 5	In addition to what Arevos said, it depends on where you're getting data from to feed into the database and what you're doing with the data you get back from it. For example, if you're getting data from a GUI, it is arguably better to validate data (and, if necessary) pester the user to get it right before inserting it into the database. That will avoid future surprises when the data is retrieved (and you may be able to avoid any need to validate data on retrieval). However, if the database is being fed by some other system, it may be appropriate to validate the data as you retrieve it. If you really care about security and redundancy, you will always validate data you get from another system (whether a GUI or database) or send to another system. That helps ensure your component systems respect each others interfaces, and can avoid situations were corruption of data propagates.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Programming Forums > Application Development > Software Design and Algorithms

Domain Object Validation