Views: 8.2K
Replies: 1
Archived
|
Is Strategy Pattern the right pattern for this?I have a user control for a menu, which has events for Add, Edit, Delete etc... I also have a form with five tabs.
Now I need to configure the menu for each tab. There are a total of 20 events being registered, that is, 5 tabs * 4 menu buttons. I tried to achieve this using the Strategy Pattern, but I am still not sure where this is the right Pattern Approach. So, I am looking for some guidance. Thanks in advance. The sample code is below: using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Reflection; namespace ConsoleApplication2 { /// <summary> /// Test Class /// </summary> class Program { static void Main(string[] args) { UI ui = new UI(); ui.Call(); Console.ReadLine(); } } /// <summary> /// My UI CLass /// </summary> public class UI { UserControl uc1 = new UserControl(ModuleName.Call);//object of User Control 1 UserControl uc2 = new UserControl(ModuleName.Project);//object of User Control 2 IControlFun Ifun = null; IController icon; public UI() { uc1.Add += new EventHandler(Add); uc1.Edit += new EventHandler(Edit); uc2.Add += new EventHandler(Add); uc2.Edit += new EventHandler(Edit); } void Add(object sender, EventArgs e) { icon = (IController)sender; Ifun = icon.GetModule(); Ifun.Add(); } void Edit(object sender, EventArgs e) { icon = (IController)sender; Ifun = icon.GetModule(); Ifun.Edit(); } public void Call() { uc1.fAdd(); uc2.fAdd(); uc1.fEdit(); uc2.fEdit(); } } /// <summary> ///Enum for Module Name /// </summary> public enum ModuleName { Project,Call } /// <summary> /// Interface for User Control /// </summary> public interface IController { IControlFun GetModule(); } /// <summary> /// User Control /// </summary> public class UserControl:IController { public event EventHandler Add; public event EventHandler Edit; ModuleName _moduleName; IControlFun ifun; public UserControl(ModuleName moduleName) { _moduleName = moduleName; } public IControlFun GetModule() { switch (_moduleName) { case ModuleName.Project: ifun = new BL1(); break; case ModuleName.Call: ifun = new BL(); break; } return ifun; } public void fAdd() { if (Add != null) Add(this, new EventArgs()); } public void fEdit() { if (Edit != null) Edit(this, new EventArgs()); } } /// <summary> /// BL logic for Module one /// </summary> public class BL:IControlFun { public void Add() { Console.WriteLine("Adding of first control"); } public void Edit() { Console.WriteLine("Editing of first control"); } } /// <summary> /// BL logic for Module two /// </summary> public class BL1 : IControlFun { public void Add() { Console.WriteLine("Adding of second control"); } public void Edit() { Console.WriteLine("Editing of second control"); } } /// <summary> /// Interface for BL /// </summary> public interface IControlFun { void Add(); void Edit(); } } Imran Khan, Jul 26, 2010
|
|
Reply 1Just my thought on this. I don't see any issue with what you have presented. Thinking in terms of your code what areas are likely to change?
Just an observation. Your "GetModule" function seems to be fragile as that may change because that is a "switch" statement. Abstract that away to a factory and your design will adhere to the "OCP (Open/Closed)" principle as you add functionality without modifying or breaking existing code. Your use of Strategy pattern for BL can be justified because you are just trying to abstract away the algorithms (in this case business rules) that varies. But if your BL are an extension of existing business rules you can combine that with "decorator" as well. "Others can comment as well". Some other thoughts: Menus and actions can be tied up using the "Command" pattern as well. Regards, Rajesh Pillai Rajesh Pillai, Jul 31, 2010
True. The other thing about the MVC pattern is that it promotes a convention, which in my humble opinion, is great! Learning to use Design Patterns correctly will, as Christian states, reduce the need for any particular presentation layer. Which is also a good thing. And by following some conventions, even some that you define yourself, will help make your application stronger, IMHO.
Aug 13, 2010
Funny thing is: The idea behind MVx is that it is easy to swap out any component if the overall design IS already following MVx. You say it was easy to swapp an ASP.NET UI to ASP.NET MVC UI.
This is exactly what I expected to hear: If you have a more or less well designed application, you don't necessarily NEED an MVx design for easily replacing the view layer with another technology.
This thesis reduces the advantage of a MVx approach (that is often underestimated in terms of necessary intial effort) to the second of the mostly acknowledged topics: Testability.
Jun 21, 2010
|