Say you have an abstract base class Task
which is a task a user can complete. There are two concrete Tasks: SimpleTask
and ChecklistTask
. What if you wanted the (ASP.NET) UI to show a different control based on which type of Task it is?
In WPF you could use DataT开发者_运维知识库emplates, but what is a nice way to do it in ASP.NET? We are trying to avoid a switch statement by the way. We have other pieces of code with long switch statement which started out small, but grew in time. That's what we're trying to avoid.
Is there a design pattern for things like this? We can't let the Task
classes 'know' the UI classes because they're are domain classes. Or is a switch statement the best we can do (if necessary hidden in a seperate 'factory' class)?
Something, somewhere, has to know how to map the Task subclass to the UI control. Period. The only question is where to put this knowledge.
- The Task itself
- A class that can use data retrieved from the Task to find an appropriate control
- The code that actually gives the Task out (why can't it give the UI control instead?)
- Some code that maps the Task class to the UI control, possibly via attributes and reflection.
- Some other kind of metadata.
Assume your SimpleTask implemented in SimpleTask.ascx, and ChecklistTask in ChecklistTask.ascx. Then put into metainfo (in any way you need it to create particular control) path where .ascx resides (eg.: "~/MyControls/SimpleTask.ascx" ).
And at last: embed control with TemplateControl.LoadControl
I love the "Isolation" part of any design pattern, look I think you should make tow UI implementations for both simple and checklist tasks, and both are just a black box for itself, then on another control or page you can use ItemTemplate
if you going to list some tasks and in this ItemTemplate
you just put a condition to check the type of the task and on it call a method on this page that render the html of the right type (Simple
or Checklist
)
精彩评论