C# DAL vs PL Logic Separation

Question

I am trying to write my first true multi layered application and I was wondering in a winform application does it "break" the DAL/PL separation rules if I were to add an object data soure to the form so I could use data bound controls instead of going through my BLL and then to the DAL to get the data?

Thanks.

Answer 1

It depends on how you define your separation in this particular application. If you have two separate ways of getting data (one from your data source object, one from your BLL/DAL) then yes this could be construed as a violation of the principal since you no longer clearly have a point at which the application can be separated.

If your Data Source is exposed as your point of interaction for the DAL, then this becomes a better model.

The idea of separation is to put as much of the separate parts of your application into modules that can be easily worked with (including swapping out, though this is not necessarily a primary concern). This means that you need to have well defined (and easily identifiable) points of interaction between libraries/modules in your application.

Ultimately the choice comes down to what is easier to maintain/extend in the time given for the project/application.

Answer 2

Using an ObjectDataSource in this manner does not necessarily break your separation of BLL/DAL logic. When using an ObjectDataSource you can specify the BLL actions which manipulate objects in your model, which in turn may use your DAL internally. The ObjectDataSource effectively provides the plumbing between your UI and BLL/business objects. The BLL and DAL separation can still exist.

However, in the context of WPF, you may want to pay close attention to the Model-View-ViewModel pattern which is being promoted as the best way to develop WPF applications. As far as reusability between WPF and WinForms is concerned, I believe your business objects, BLL and DAL should fit this (they would constitute the 'Model' in MVVM), as they should have no UI considerations built in. However, as for the mechanism for binding to views and actions in the UI, you may find this is the natural point of divergence. It is likely that WPF will be more widely used in the future than WinForms, and I would not advocate a bastardising a WPF pattern purely to make it reusable in WinForms.