2

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?

casperOne
  • 73,706
  • 19
  • 184
  • 253
SRKX
  • 1,806
  • 1
  • 21
  • 42
  • 1
    You should have different class sets in each layer. Sounds a bit redundant but it's the correct choice (as evidenced by your doubt) – Sklivvz Sep 11 '11 at 21:34

1 Answers1

1

As mentioned by Skliwz in the comments, the correct place to place this is in objects that are specifically bound to the UI layer.

If you are binding your business objects directly to the UI layer, and you find that the INotifyPropertyChanged interface doesn't really belong on your business objects, then it's a clear indicator that you should have different objects for different purposes

For example, you might want to have a view model, using the Model View View Model pattern.

However, if you find that your business objects are to be monitored by other systems, and you need notifications as to when they changed, then the INotifyPropertyChanged interface is appropriate. However, it sounds like in your specific case, it is not.

Community
  • 1
  • 1
casperOne
  • 73,706
  • 19
  • 184
  • 253
  • Thanks for the MVVM link, however, I'm not sure what you mean with your last paragraph. Why would `INotifyPropertyChanged` be inappropriate? – SRKX Sep 12 '11 at 09:17
  • 1
    @SRKX: Well, I can't say for sure, but typically, the UI elements are served up by a proxy (WCF, RIA, etc) which automatically generates these objects for you. These are *not* your business objects, they are representations. You typically want something like a view model to handle specific UI interaction (button presses that link up functionality and the like). However, if you are on a back end, and you have your models in memory, and the property changing sends a message to say, MSMQ, then it makes sense for your objects to implement `INotifyPropertyChanged`. – casperOne Sep 12 '11 at 12:03
  • 1
    @SRKX: However, it seems like in your case, you want to bind to the UI. I'd recommend a view model that encapsulates the business object, possibly implementing `INotifyPropertyChanged` itself, as well as any addition properties that help with binding the data to the display. – casperOne Sep 12 '11 at 12:04