RSS 2.0 Feed
RSS 2.0


Atom 1.0 Feed
Atom 1.0

  The Art of Multi-Layered Design 


qt8gt0bxhw|20009F4EEE83|RyanMain|subtext_Content|Text|0xfbffd10000000000d000000001000200

Scott Hanselman posted a good reminder on multi-layered/tiered design. If you have already read it, read it again and live it. If you haven't read it yet, then shame on you for not subscribing to Scott - and you call yourself a .NET developer?! Go read it.

When I am training developers I find that I spend more and more time on this topic. I find that it is not something that is emphasized in schools and often not understood by new developers. I am big supporter of layered architecture and just love to see a good multi-layered design. I can't tell you how bad I hate to see the use of System.Data.SqlClient/OleDb or even System.Data in the presentation layer. There's a place for that stuff and it is definitely not there. If this is a new topic for you - don't go to sleep again until you get it. Once the reasons why a layered/tiered design is such a big deal “click” for you, you'll never go back to your former bad practices. Pure bliss.

But it's not so much of just knowing how to design a multi-layered application. It is much different to really understand it - so that it just comes out natually in your designs. It takes experience, but it is not an unattainable level of experience. Make it a point to properly design your applications. Any application, no matter how small. As far as the argument goes that it will increase the duration of your design and development phases. Well, it might at first. However, the payoff is huge and once you start to understand it you'll have a hard time thinking about your designs any other way.

Also, since this tends to be a part of the area of confusion that new developers have at times, I wanted to pass along a quote that Ken Robertson left in the comments on Scott's post: “hardware architecture does not determine software architecture, code does”.

BTW, while you are at it, follow-up with reading Scott's post on why you should be returning domain objects from your web services instead of DataSets. Working with domain objects, whether from web services or elsewhere, makes for more concise and natural code. Why work with a “bowl” when what you really want is the “apple”? Take a look at my previous post on returning objects from web services for more info.




                   



Leave a comment below.

Comments

  1. Vijay 1/31/2005 12:23 AM
    Gravatar
    it was short and concise...
    where i can get more detail?
  2. Ryan Farley 2/15/2005 9:12 AM
    Gravatar
    Vijay,

    The best way to learn is to grab & study some open source apps written in .NET by people such as Scott Watermaysk (.Text). This will show you a lot of good design techniques.

    -Ryan
  3. sweety 1/9/2009 1:55 AM
    Gravatar
    I am last sem B.E. computer student.
    in the last sem I have to create one web application and my web application is like as jobs.com or I can say seeker for job.So I am confuse that how can I start am application.So please help me for this project.
Comments have been closed on this topic.



 

News


Also see my CRM Developer blog

Connect:   @ryanfarley@mastodon.social

         

Sponsor

Sections