I have separate library (Controls.DLL) with my custom Controls.
I have another library (Model.dll) with my data access code.
Some controls do need access to data. I’d like to keep those libraries loosely coupled. Basically, I’d like to acces data without referencing Model.dll
What is the proper way to do it? Naturally, I think Binding is a way to go. But it’s not just binding to data, I also need to execute actions against my model (retreive data, paging, filtering). And I need to study metadata that my model contains.
For example, I have Customer class with properties like “FirstName”, “LastName”, etc. But I want those to be displayed inside my control with captions like “First Name”, “Last Name”. This is primitive example but it kind of shows my point.
My other idea was to have “providers” on data side that would spit out XML and on control side I will parse this XML. But how do I go about methods?
Another idea is to go with reflection. This way I would just pass object to Control. But I’m not as good with reflection and not sure if I can achieve things like: getting properties/attributes. Getting and executing methods? This sounds like a perfect thing to code with Interfaces but Interface need to live somewhere and therefore something have to reference something.
So, what is the best way to code loosely like this?
Check out the MVVM pattern (Model-View-ViewModel).
Basically, a ViewModel wraps a Model, and exposes data access and data manipulation commands to the user interface (the View) via property bindings.
You’ll find heaps of documentation, tutorials etc. by searching for MVVM. Or check out this StackOverflow answer to get you started.
Update:
MVVM allows you to separate custom controls and data. It sounds like you want to dynamically generate interface components based upon data in your model. You can do this in MVVM (it’s not the only way, of course). The view model can dynamically generate collections based upon the model. The view model can include methods for converting raw data to display data. This means neither your model or controls (view) need to know how to
do this.
Depending on the nature of your data, you may choose to have `generic’ view models reflect over property names to procedurally generate display names (as in your primitive example), or you may choose to write specific view models for specific data in your model. That will depend upon the nature of your data. Either way, your custom controls (in the view) remain decoupled from the model.
Update 2:
Your view models do not need to live in the same assembly as the view (controls). You can even put them in a third assembly (as described here). Of course that encourages you to follow MVVM more strictly and make sure you have no dependencies from ViewModel to View, but that’s a good thing. There are a few more hints on the issues related to hooking up views to view models you may encounter here.