I am at the moment creating a project large enough in my opinion to separate carefully the well-known layers in its architecture.
For the data access layer (DAL), I simply use the .NET Entity Framework.
For the business layer, I defined business objects which are then available to subsequent developers who can use them to create clients and handle the UI.
As I have to develop a client application as well for demonstration purpose, I realized that it can be very helpful to have an ObservableCollection<T> instead of a list, and that as often as possible the objects should implement the INotifyPropertyChanged interface so that the UI automatically detects the changes and displays the updates straightaway.
Yet, I wonder whether it is really the right way to do from a architectural point of view. That is, technically, I don't think the business layer should have anything to do with UI display as we do not really "know" what a programmer might use it for; he might just want to use the objects for computational purposes for example. Hence, I was wondering what was the common practice?
Should I implement these features in the business layer (there would be no performance issue)? Should I create some kind of "decorator" object in another layer which includes all these features?
