Design Patterns and nTier for n00bs - WTF?

Hi all,

I'm currently writing an application using the .NET Platform (C# 3.5).  I"m not a professional developer but I can code at an intermediate level - let's get that out of the way first.  I want to try and 'architect' the application properly from the start but unfortunately that means probably doing things that I don't know exist ... enter design patterns.

Can anyone offer any advise on design patterns for someone like me?  Which one would be the best to use for a site that, for the sake of example, is like Flickr?  There are members, there are photos etc.

Also, if the application as a UI and then needs to update member information, should the UI talk to a model layer which, in turn, talks to a data layer?  Or is it ok for the UI to talk directly to the database?

I realise these might be entry-level questions for a pro dev but they're pretty mind-boggling for someone like me.  :)

Who is Participating?
marklorenzConnect With a Mentor Commented:
I believe that patterns like MVC are fundamental for any quality software. See if this helps:

Introduction to Model View Control (MVC) Pattern using C#

As for the UML diagrams, they should help the developer analyze and design a system well.  I use them even if I'm the only one working on the software under analysis.  Companies I've worked for have been thankful that the design is documented, plus it helps me to generate code skeletons from the UML.
marklorenzConnect With a Mentor Commented:
First of all - kudos for wanting to do things the "right" way.  So many "professional" developers don't go the extra step.  That said, the first, most fundamental pattern you need is MVC - Model/View/Controller.

Briefly, this pattern (which is used in many modern tools and frameworks) says that you should layer your application into at least three parts:
(1) the model - the business logic that gives you reuse
(2) the view - which is your UI, whether native or web
(3) the controller - which is the logic that handles the user's interactions with your application

As for the application itself, the most important thing is to model the domain well.  That means to analyze the concepts (classes) and behavior (methods) that exist in your problem space.  In your case, that means to understand what it means to be a "Flickr" type app.  You should capture this analysis and related design in UML - Unified Modeling Language. This is the de facto standard for OO analysis and design. Specifically, you will need class, sequence, and perhaps state diagrams (you can certainly do more - these are the minimum required in my experience).  The information in your UML model correspond directly to your implementation - that's the beauty of OO.

Here are some references:
synopses for the design patterns

UML Basics

Best of luck!
marklorenzConnect With a Mentor Commented:
Oops...forgot to answer your question - no, the UI should not talk directly to the DB.  The model layer should always come between the two.  Think of the DB as merely supporting the persistence of the state of the model - i.e. the DB is not the center of your app, the model is.

E.g. Flickr has pictures, accounts, ...  When a user creates an Account, you will of course need to persist it so that it exists when they log on again.  That's where the DB comes in... but - the model decides that it should be persisted, not the UI or the DB (though it may be "triggered" by an action on the UI).
Number5ixAuthor Commented:
Hmmm interesting.  I've got a couple of observations/questions there.  Because I'm writing the app using C# wouldn't trying to use MVC be a little tough?  MVC for .NET is still only in Beta after all and I've heard about .NET's architecture not really working with MVC for a couple of reasons, some of which are the viewstate model and the requirement for rewritten URLs.

I understand the value of class/sequence/state diagrams but I would've though they were more aimed towards commercial/professional applications where the various layers and interactions are going to be looked at by different teams that aren't necessarily in contact and working together the entire time.
Number5ixAuthor Commented:
Not exactly what I was after but this was a question without one "correct" answer.  I'm splitting the points as I believe marklorenz helped somewhat when nobody else would but no single response was the exact solution.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.