While not directly applicable to CSLA, because that part is actually the easiest to put together, I am trusting that the knowledge and experience of this forum's contributors will prove once again that this is the best place for me to post my issues/questions. I'll use a specific example to highlight my questions. But first, a little background...
I have been tasked with developing an application that will be deployed on multiple front-ends using either Windows Forms, WPF or ASP.NET. To ensure code-reuse and common behavior, we are trying to implement a multi-tier architecture following the MVC design pattern. In addition, to support extensibility, scripting, etc., we are looking at creating an Automation-style API. The Model is completely comprised of CSLA business objects and, as I said, is the most straigh-forward part of putting this all together.
That said, let's take a quick look at how I've thought about implementing the (simple) File->Close operation to discuss my issues/questions.
I've defined a CloseCommandItem class in my object model that the presentation layer (WinForm, WPF, ASP.NET, etc) binds to when rendering the command in the UI. This class, which derives from a CommandItem base class, exposes properties such as Caption and Enabled and a Click method that carries out the operation. A few notes about the class:
As I've explained some of the benefits above, I am concerned that I am making a mountain out of a molehill and creating a ton of extra code, etc. by creating a separate class for each menu/toolbar item in this manner. However, it seems to me that this is good OOP given the business logic associated with each item's state management and behavior.
Furthermore, should I just raise a simple PropertyChanged event from the class or go with the individual events? I am not fluent in WinForms nor WPF data-binding but it seems to me that we should be able to bind the UI controls to the CloseCommandItem and specify that the Enabled property of the control is bound to the Enabled property of the command item. Am I correct that data-binding would handle refreshing the property if we raised a PropertyChanged event but won't know how to do so if we go with the EnabledChanged event instead.
Next, under the MVC pattern, I am a bit unclear who should be in charge of "building" the menus and toolbars. If we have all of these built-in command items, something needs to be responsible for assembling them into the Application.CommandBars collection that the presentation layer then binds to. Examples I've seen typically show the UI deciding which menu items to show and have then hard-coded through the form's designer. This seems to be contrary to what we are trying to do. My initial thought is to have another class that represents the File menu, instantiates all of the "built-in" child items and adds them to its ChildItems collection. In the same regards, any cascading item would be responsible for creating its child items. Then my CommandBars collection would simply know to create the top-level command items (File, Edit, View, etc.) and add them to itself. Make sense?
How does this work with or conflict with the new ICommand architecture in WPF (RoutedCommand, RoutedUICommand, etc.)? Obviously I want a solution that works across multiple front-end technologies so depending on WPF is not practical but I also don't want to reinvent the wheel nor eliminate capabilities provided by the framework.
Any other flaws in this approach? Anything I'm not thinking of or missing? I have much work ahead of me and don't want to wander too far down the wrong path, so your input is appreciated.
Thanks in advance.
I started to create an Automation API around my CLSA classes just for a winform application. So I'm not sure if this would work in a WPF application. I basically went the route of using the property notify change event instead of creating specific events and I'm starting to wish that I had specific events mainly for readibility. I also created a bunch of individual classes to represent menus and menu items that are independant of the infragistics menu control that I use. It is a lot of extra work but it does make coding the actual UI a little easier because all you have to do is respond to events to update the UI or use the automation api to change the application. I have a command window in my application that I can write .Net code snipptes that are dynamically compiled and the UI responds just as if the user did it.
As for the menus, I have an usercontrol which is a wrapper around the infragistics menu control that listens for events from the menu collections and menu item property change events. This user control is responsible for updating the UI either by adding or removing menu items or changing the enabled or visible property of individual menu items. Since the usercontrol is listening for menus getting added, I let each module add what ever menus each module needs.
I'm really intersted in the automation api style of creating applications and hopefully we can continue to bounce ideas around about this.
Happy Jack
Copyright (c) Marimer LLC