I am writing an ASP.NET application which I have a UI layer, business logic layer, and data access layer. From my data layer I return business objects to the business logic layer and pass these on to the UI layer. However, I'm not sure what to do when I want to perform a save/insert with data from the UI layer.
Should I create the business object at the UI layer and pass on to the business layer or should I be creating it in the business layer?
many thanks
I find it better to have UI layer objects that model the "real" business objects. These model objects don't need to have all the information (associations and such) that the "real" business objects have. Then the business layer have to be in charge of converting from and to business objects.
For web-applications this is particularly handy, since you don't need to send excessive data back and forth to the client.
I agree with crunchdog-- for all but the most trivial web applications you should have a flattened form of your business objects specifically for your UI/view layer. Sometimes this is referred to as a View Model class and generally contains nothing more than several string properties that the UI layer can get from and put to directly without worry of validation. (see asp.net mvc)
For one, this keeps the UI layer cleaner and simpler, leaving it to put it's efforts toward displaying the data rather than traversing object structures, checking for and interpreting nulls, etc.
This also gives the business layer the opportunity to do validation upon those string values, returning the values as entered if they are invalid. This can save coding frustration when, for example, your server has to handle an invalid date in a date field. The business layer, recognizing the invalid values, can return them exactly as received along with the proper error messages. If all you dealt with were business/domain objects, then some values entered may not always fit the objects intended to hold them.
It can also help to have a class designated for mapping values back and forth between the business/domain objects and the UI object/view model. This helps keep the business layer concerns cleanly separated.
If you don't want excessive coding of business object then you did the right thing on retrieving data (where in you return the same business object from DAL to BL to UI).
On saving data what you could do is pass those objects as parameters on your BL and\or DAL layer. You could either pass the current object back if you binded it on your UI control or create a new instance of that object and set the changes done.
Then on your DAL layer just read the object and save the changes back to the database.
I've found that the easiest solution is to have a View Model object passed from the UI to the Business layer, for a couple reasons. The most obvious is that validation should happen in the business layer, so creating a business object in the UI breaks the principles of MVC.
More importantly, if the user inputs invalid data, a business object may (properly) not be capable of accepting that data. However, you don't want to throw out the data the user entered, so a validation-free View Model object gives you a way to store and pass around the data the user entered, whether or not it's valid.