Custom UIView as UITableView delegate and datasource?

I am writing a fairly complex iPad app - my first bigger one.

This app has some custom UIViews that present fairly complex data, including a table. These views do not take up the whole screen, and there can (and likely will) be many of them on screen at any time (though only one would be in an "expanded" state where the table is shown).

Here's a basic example that should convey the basic principle:

Please note that these things are not supposed to be in popovers; instead, the FamilyViews expand to show their detailed data. (And please also note that this mockup was only created for the sake of this question and has little to do with how my interface is going to look; I know this is not good screen design)

I'm undecided on who to put as the delegate and datasource of these custom views:

• Making the ViewController for the current screen delegate and datasource is unelegant, because it's not just one table that's part of the VC's main view.
• Making the View itself the delegate and datasource seems a bit weird to me because it feels like giving the view too active a role; making it into a half-controller.
• Making the underlying model object the datasource seems too tightly coupled, and also breaks MVC. And it doesn't answer the question of who should be the delegate.

I'm tending towards making each of these "开发者_高级运维FamilyViews" delegate and datasource for their own tables. Action on these tables will have to be coupled to the FamilyView's delegate (the ViewController), but that shouldn't be a problem, should it?

Anyone have some input on this?

---

Views should know how to paint themselves and layout their sub views, depending on their properties, and that's it.

You definitely should let a controller class be the delegate instead of the view itself.

The delegate controller doesn't have to be the view controller that displays the view, though. It could easily be a completely separate controller class that only knows how to handle what the view requires.