views:

207

answers:

2

I am a dotnet newbie. After years of procedural coding, my company is moving on to the HOTTEST new trend i.e WINDOWS FORMS :)

Our Application is TabbedMDI. Basically we have a menu on the left and clicking an entry opens a new tab for CRUD. I have seen some MVP samples that have a couple of textboxes and it demonstrates moving the code behind to a Presenter class to make it TESTABLE! We have more complex logic than that.

I've heard Jeremy Miller talk about Presentation Patterns and Screen Activators and Screen Navigators etc. Sadly there are no Books on UI Patterns whereas there are tons of books on other patterns where they talk about inheriting from Animal class to have the cat Meow and a dog Bark.


So my question is this:

Let's say we are building tabbedMDI form dynamically based on information coming from somewhere like(XML, WEB SERVICE or in our case tables in database). After the form is created, there is a lot of logic whether the toolbar buttons are enabled/disabled; when and if we can navigate from tabpage to tabpage.

Navigation rules are different for the first page and other pages and so on. Validation involves not only what fields are shown on the form, but hidden fields. Some fields are validated against database and not simply being blank.

There are a lot of other requirements and for the sake of brevity I won't mention. THIS IS OUR FIRST PROJECT!!!

Where do I begin separating out the Navigation logic, Validation Logic, Tab activation logic?

Right now I have all that logic in the code behind because more often than not I need to have values from other form controls and/or underlying datasource to determine if switching tabs is allowed or whether I disable Toolbar buttons or I display error message etc.

I have seen SOLID with payrolls and employees. How can we apply that in UI design?

If someone has stumbled upon UI Pattern Blogs please point them out. I have gone through the 'Build your own CAB' series.

+1  A: 

We have more complex logic than that.

That's an argument FOR testability, not an argument against.

Sadly there are no Books on UI Patterns...if someone has stumbled upon UI Pattern Blogs...

Curiously, there are a lot of websites that talk about UI patterns. http://www.google.com/search?hl=en&source=hp&q=UI+patterns&aq=f&oq=&aqi=g10

Robert Harvey
mostly on web interfaces. and they talk about end user experienceNOT how to apply design patterns in implementation.
codemnky
Martin Fowler's website is pretty much the definitive work on design patterns.
Robert Harvey
been there. I know there are Orders and Customers and Shipping addresses. Those are business concerns that belong in the middle tier and how to use specification patterns to separate GoldCustomer from SuspiciousCustomer. I get that! I am talking about the FRONT END. Presentation layer!
codemnky
Well, you already know about MVP. What are you waiting for?
Robert Harvey
+1  A: 

Okay, so here's the key to most patterns.

Don't think of your program as a series of instructions. Think of it as a series of 'servers', each sending messages to each other. The UI 'server' sends messages to the View 'server' when a button is clicked. The View 'server' sends messages to the Order 'server' to start an order. The Order 'server' then sends a message back to the View 'server' tellling it about the order, and the View 'server' sends a message to the UI 'server' giving it the data to display.

That's a quick example of what the MVP pattern really means. If it helps, instead of thinking about 'servers', think about people sending letters to one another.

kyoryu
are you talking about SOA patterns? I have no idea how that relates to Client Side Presentation
codemnky
No, not SOA, but rather thinking about your program as little 'services' that communicate with each other.
kyoryu