n-Tier Design Question

Kevin Marois

I'm working on a busisness app for a client. Right now it's a WPF app. I have the UI layer, the BL, and the DAL. 99% of the BL just passes the call to & from the UI/DAL. Now, I'm going to be introducing a Tablet piece. In the WPF app's ViewModels I have a Validate method which checks to see if the required fields are filled in, and also some business logic. One example is "You cannnot save a Job if the Approiver has not been set" So, in the tablet app, I'm going to want to do the same logic.... when the user clicks Save, validate required fields and apply business rules. So It seems to me that the BL is a good place for this. However, its also seems that passing all the data across the web to a Web API, only to have it rejected in the BL, isn't right. Is this the right approach?

If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.

Richard Deeming

I'd be inclined to have a shared class library of DTOs used to communicate with the API, and put the validation in there. Then have the UI view-models delegate as much of the validation to the DTO as possible.

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

Kevin Marois

Richard Deeming wrote:

I'd be inclined to have a shared class library of DTOs used to communicate with the API, and put the validation in there.

That would be fine if the only issue were missing property data. The DTO'scould validate themselves. But in the case of business logic, there are times when you would need to go to the data. Plus, putting the validation in the logic means that the DTO's can only be used in that app. If you then created another app that uses the same data, then the DTO's are now housing logic specific to the first app. The second app may not require the same validation. IMHO, DTO's should be dumb objects that do nothing but carry data.

If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.

TimWallace

It is generally a bad practice not to validate one's data that has been sent via the internet to an API before committing to a repository/database. If the volume of data being transmitted results in a sluggish UI, perhaps the core design is incorrect and should be reevaluated.