Architectural Problem, i cant find where validate

Topics: General discussion, Validation Application Block
Sep 6, 2007 at 12:20 PM
Hi, im starting a new enterprise application, first in .NET (2.0) and i want to use VAB to my bussiness objects, but i try explain my design:

Putting all in "MS Northwind" terms my Customer objects are created from a factory and must exists in the database, there is no default empty constructor and his attributes are only read-only (just public get), for exeucte actions to modify a Customer you need a CustomerManager object, this class can create a new customer but doesnt have the Customer Properties, it has a static method wich receives the customer info (lot of parameters) and uses the DAOs to add the customer record to database.

Im not happy with this AddCustomer method but still cant think a better solution (im sure there are), anyway my problem is a want to have customer validation to bussines layer and use it in WinForms and WebForms, i like the attribute approach but i dont see where to put attributes.

Can you people give me some guidance...
Sep 6, 2007 at 5:19 PM
How do users go about editing your Customer object if the properties are only getters?

I'm going to assume, for a moment, that you have some method on your CustomerManager that allows you to update fields on an individual basis. So, for instance, you could update their Name if necessary (I am not sure how you would do that with your Manager if the underlying Customer object's Name field is readonly without resorting to Reflection).

The way to perform validation via Attributes is to put the Attributes on your Properties for your Customer object. So, like this:

public class Customer
{
   private string _name;
 
   [StringLengthValidator(1, 50, MessageTemplate = "Name be between 1 and 50 characters")]
   public string Name
   {
      get { return _name;}
   }
}
 

Now, when you setup your ValidationProvider, you will need to tell it to use the Customer object as the SourceTypeName. Once you setup the ErrorProvider and the properties on a Forms TextBox, for instance, then the validation will happen between the TextBox's Text field and the Customer's Name field.

The only problem I see is how you're going to actually have a Form or other UI control update the Customer data. I don't really see why you're going to such great lengths to make your business objects so incredibly complex and developer unfriendly.


Sep 7, 2007 at 12:21 PM
Hi Chris, i dont want to make complex and developer unfriendly things, but also i dont want bussines objects that can be modified everywhere, its matter of make solid components, Customer is always a real customer with valid data inside and exists in the database, if you need take actions for this customer you use a CustomerManager both classes uses the DAO for the Customer. I think this way i get more performance because Customer has a base class and this classes are pooled in the factory, so always i get same Customer instance when i ask for him, also i reduce the amount of Applicattions where Customer is modified. The "Manager" Classes are more complex, have different role, anyway its just a starting design, sure its going to change but remeber my contex think you are developing a Customer class to be used in the whole SAP modules for example.

Im building a reference framework for built really big enterprise applications, maybe using SelfValidation in the CustomerManager is the way...