Some UI design questions

ajj3085 posted on Thursday, January 11, 2007

HI all,

I have now two applications (exe) that I will be supporting.  Both operate on the same database and they share a number of screens.  Both use a Software business library and Contacts business library. 

To get things going more quickly, I copied the forms from one application into the other so that they are totally seperate.  Obviously this isn't ideal, but I can deal with it for now.

In the very near future though, I'm thinking of moving most of the forms into UI assemblies, based functional areas.  So the screens relating to software would be Software.UI, contact screens would be in Contacts.UI, etc.

Now, some of the forms currently are dependant on each other.  For example, the SerialNumberFind form uses the CompanyFind and DepartmentFind forms so that the user can select a department as search criteria to find all serial numbers belonging to a department.  Likewise, SoftwareRegistrationEdit form uses ContactFind form so that the user may lookup an existing contact to for the registration information.

I'm trying to decide if I should keep these seperate.  One advantage is that there's actually a third business library which one of the apps will never need access to, and thus wouldn't have an dependancies on it.  Another is that it keeps each assembly smaller and hopefully easier to understand.  To break the dependencies, the SoftwareRegistrationForm could have an event, ContactRequest to request that a contact be provided by someone else (likely the main form). 

Alternately, all the screens could be tossed into one assembly.  Then applications would just use this one assembly.  One advantage is that if an app every needs a UI already defined in the common UI assembly, its already there.

What does everyone think?  I'm leaning toward the seperate route.  I'll have other 'applications' later, and it seems like it would be easiser to only select functional areas I need.

Thanks
Andy

rlarno replied on Friday, January 12, 2007

Andy,

Just my 0.02€

I would focus on having your components (UI or otherwise) clearly seperated in different namespaces. I always tend to start out putting everyting in a single project (~ assembly) since this keeps things very simple to refactor and move code around. I use project folders a lot to keep the code visually strutured, following the namespaces used.

Splitting items up into seperate assemblies, is a decision to be made because of deployment choices. For web applications, I tend to stick to as minimal assemblies as possible. For Windows Applications, it really depends on keeping the features that will always be used together in the same mininal set of assemblies. E.g. the main form uses component a, b, and c, and classes x, y, z, so if all of these live in the same assembly, these all get loaded from disk immediatly. Optional features, one-time configuration wizards, or option screens, or help or about stuff, can live in a seperate assembly, which will not be loaded until the funtionality is required. This sort of splitting up code into assemblies can help manage the working set of large windows forms applications.

SonOfPirate replied on Friday, January 12, 2007

My recommendation is to restructure your apps using a multi-tiered architecture where you have a common assembly used by both (all) applications.  This is, in fact, how I approach all applications I design because (as I've mentioned in other posts), you never know what the future will bring!

So, in my case, I will typically have a common assembly that contains all of the common business object, UI controls, forms, etc.  I think we all find the idea of a common assembly for BO's intuitive but hesitate when it comes to UI elements.  Just think of this as an extension to the old CommonDialog concept or a continuation of what MS provides in the FCL, e.g. PrintDialog, etc.

As a result, you'd end up with a common assembly referenced by each of your applications making it easier to add new application making use of the same common BO's and UI elements along the lines of:

[AppName].[Version].[dll | exe]	Software.v1.00.exe	application assembly
[AppName].[Version].[dll | exe]	Contacts.v1.00.exe	application assembly
[FamilyName].[Version].dll	Common.v1.00.dll	common assembly

(Kinda like Word, Excel, etc. all make use of common Office - the family - assemblies.)

As for the question of dependancies between the forms, etc.  I would do what I could to break these.  The idea you had to make use of events and have the client application determine how to respond is best.  This will provide better flexibility down the road should you have a new app that you need a different ContactFind form, for instance.

You can use a trick that I've adopted if you want to provide default behavior that can be overriden when needed:

public class SoftwareRegistrationForm : Form
{
    public event EventHandler ContactRequest;
   
    protected void OnContactRequest(EventArgs e)
    {
        if (ContactRequest == null)
        {
            // Default behavior
        }
        else
            ContactRequest(this, e);
    }
}

This way, you can wire-up the forms to emulate their current dependancies but allow customization later.  If you use explicit declarations for you revents, you'll obviously have to tweak the example...

HTH

 

ajj3085 replied on Friday, January 12, 2007

Sounds like you're advocating the split.  I already to have a common UI library, which contains an About form that can be reused and a message notification component I have, which runs in the background and provides messages to my users via a sytem tray icon.

Keeping in with your specific example, maybe I should define some interfaces which common forms should implement, like IContactFindForm.  That would keep the specific forms decoupled while adhering to a standard.. or maybe that's going too far.

I'm not sure the 'default' behavior would work, because if there's no handler the RegistrationEditForm won't know anything about the contacts business layer at all, and won't be able to do anything if there's no handler..

SonOfPirate replied on Friday, January 12, 2007

Yea, the default behavior would require that you've fully implemented the forms and requisite (extensible) BO's in the common assembly.

ajj3085 replied on Friday, January 12, 2007

rlarno:

Splitting items up into seperate assemblies, is a decision to be made because of deployment choices.

Well I also think you would split them to be able to reuse them as well, which is what I'm coming up against at the moment.  Its not so much that I'm losing track of the forms, its that a fair number are now needed in a few places.  Reusing forms across applications will also help me keep a consistent look / feel across applications.

That's a good point about keeping less used code in a seperate assembly to speed load time.  I'll have to remember that moving forward.

ajj3085 replied on Friday, January 12, 2007

Actually I'm thinking about the seperate assemblies idea, and I think what you might be getting at may be to have multiple assemblies, possibly one that only contains forms related to looking up contacts, and the other with the edit forms.. that'd be a great idea I think.

The software application doesn't need any of the forms to edit contacts, it only needs to look them up.

The downside is now I'll have potentially 2 or more UI assemblies per functional area, but that might be outweighted by the fact that applications won't even see forms it really won't ever be using...

SonOfPirate replied on Friday, January 12, 2007

Not sure if I'm following your thought process completely.  But, if both apps use contacts and the ContactFind form, then I would put those in the common assembly.  If only one allows editing, then decide if you think that functionality is something that could be required for another app.  If not, leave it in the application assembly; otherwise, put it in there too.

I try to put everything related to an object together, so even though the Software application does need the ContactEdit form, because it directly relates to a basic operation with the Contact BO that is included in the common assembly, I'd include that form too.  But, that's just my preference.

Obviously there is nothing wrong with looking at what you have and moving ONLY what is common between the two apps into a common assembly.  Downside is that you may find later that something you left in the application library would be better suited in the common one, maybe because a 3rd app has entered the picture and does use it (like the ContactEdit form, for instance) and you'll have to change the app and the common assembly in addition to the new app.  But, that may be a more prudent way to go because you'll know that you have only included what you need in the common assembly and won't spend too much time trying to predict the future.

HTH

ajj3085 replied on Friday, January 12, 2007

Pirate,

Basically I'd have a Contacts.Edit.UI and Contacts.Display.UI.

The Edit assembly would include forms that help edit contact data.  The Display assembly would only be those forms that deal with displaying and finding contacts; that is, forms which don't use the editable contact business objects.

Software and Quoting would be split the same.  That way, the Software editing application would use both Software.UI assemblies, but only the Contacts.Display.UI.

The other application would be similar, but because it edits quotes and contacts, it wouldn't need th Software.Edit.UI assembly.

The main application would then only contain application specific forms and controls.  If something ends up being shared later, it could be moved fairly easily to a library assembly.

Is that a clearer picture of what I'm thinking?  Does it sound like a good idea?

Andy

SonOfPirate replied on Saturday, January 13, 2007

Sounds a bit more complicated (4 assemblies with only slightly different names and purposes plus 2 more for each additional app you add???) but if it works for you, then go for it.

ajj3085 replied on Monday, January 15, 2007

Well I wouldn't need any addition per application; application specific forms would live just in the exe assembly.