1

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?

katit
  • 17,375
  • 35
  • 128
  • 256

1 Answers1

1

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.

Community
  • 1
  • 1
Ergwun
  • 12,579
  • 7
  • 56
  • 83
  • Question not about MVVM. It's about separating custom controls and data – katit Nov 01 '11 at 12:49
  • I've updated my answer to show how MVVM lets you separate custom controls and data. – Ergwun Nov 01 '11 at 13:44
  • So, where this view model going to live? Is it on control side or on model side? I understand you suggest it stays in my MVVM structure where I use control. But that is going to be too much of code in my UI. I'd rather put most of it into control or model. – katit Nov 01 '11 at 16:01
  • I've updated my answer again to address where to put view models. – Ergwun Nov 02 '11 at 12:05
  • I understand your suggestion but it's not what my problem was. Anyway, I solved it by adding interfaces to my Control and supplying data from model by knowing interfaces. Pattern (MVVM) doesn't matter, I needed to know how to pass data into user control without referencing data. Interface and some reflection is what solved my problem. – katit Nov 02 '11 at 13:15