tags:

views:

142

answers:

6

I have a control in which we show some links to different sites based on some business rules. Currently all business logic to build link list is in control. I plan to move out the busincess logic from the control.

what will be a good design for this? can I use any design pattern?

+1  A: 

How about the Model-View-Presenter pattern?

Another good choice might be the Mediator pattern.

oykuo
A: 

I not sure how you implement your business rules but here is an idea...

I would databind your web forms list control.

public class YourLinks
{

   // You could do it by overloading the constructor...
   // Again not sure how you determine what links should be displayed...
   // If you had consistent types you could make your constructor internal
   // and then create a YourLinkBuilder see below...
   public YourLinks(User user, Region region)
   {

   }

   public YourLinks(City city)
   {

   }

   // Databind to this method...
   public IEnumerable<string> GetLinks()
   {
      // return your links...
   }

}

public class YourLinkBuilder
{
   public static YourLinks BuildPowerUserLinks()
   {
      return new YourLinks(new PowerUser(), new Region("Washington"));
   }

   public static YourLinks BuildVisitorLinks()
   {
      return new YourLinks(new VisitorUser(), new Region("Empty"));
   }
}
J.13.L
A: 

Given the little information provided, I would suggest you create a model of just the links (and its related data). So that you can pass the LinksModel to your views for rendering. Or pass your LinksModel to your existing model (as a sub-model).

Either way, all this data is encapsulated. So if you want to add data to it later, it will not change your method signatures (or general contract). If you want to remove data from it, same advantage. If you want to remove it entirely, its only one object and simplifies the removal.

You can also build links view renderers so that it and only it knows how to visually display the LinksModel. So within your view, you can delegate the visual aspects of the links info to such renderers instead of having logic within your existing view. If you want to change how links view looks later or want to give the user the power of selecting different renditions, you can simply use different renderers rather than jamming your entire code with 'if' blocks.

Jeach!

Jeach
A: 

You should use Model-View-Presenter for sure. In the view, you should have your control.
The control's responsibility should be merely to take input from the user, validate it, and pass that information to the presenter. The presenter should then interact with the model, where your business rules are stored.

From the model, you may wish to return the links that are then passed to the control for display, or you may wish to return some metadata that is passed to another system to retrieve the links.

What I would do is use the Strategy pattern in the model, so that you can easily swap in and out different versions of your business rules.

To abstract interaction with your backend datasource (if you have one) have a look at Martin Fowler's Gateway pattern.

MedicineMan
A: 

You shouldn't get too caught up in thinking about patterns. Most of the time they are overkill and add too much complexity. Particularly with a trivial scenario like this.

Just utilize good object-oriented practices and you'll be fine. Encapsulate your business logic in another class and provide public properties for your control to access it. Keep it simple!

Tim Merrifield
I believe thinking about patterns in this case might actually result in a simpler solution.
Waylon Flinn
+1  A: 

Do you really need a custom control for this?

Model-View-Controller suggests that you only have display logic in a control.

Find a solution that allows you to make small changes to a built in control (ListView) and create a custom data set somewhere else to pass to it.

Waylon Flinn