Server Side Programming and Design RRS feed

  • Question

  • Hi Techies,

    I have been out of the programming world from last one year and I got a project to design Client server application.

    This is going to be a big enterprise level application. which will start with a few features ang will grow day by day.

    Till now I have been developing small scale applications for 20 users max.

    Now whem I am starting a big application, I want to be more cautious about design and architecture... I need help from you techies..

    Could you please let me know what points should I keep in mind while designing a client server architecture?
    e.g. Scalable design, immutable objects, authentication and authorization should be part of my design

    I am also using .Net 3.5 first time, UI will be in WPF and for communication I might use WCF..

    Could you please recommend me any design patterns I should read (I am aware of only GOF design patterns)?

    Saturday, June 27, 2009 2:38 PM


All replies

  • Look into Web Service Software Factory and Web Client Software Factory.  We've used that in an application of ours, and it's wonderful.  It also does much of the coding for you. 
    David Morton - http://blog.davemorton.net/ - @davidmmorton - ForumsBrowser, a WPF MSDN Forums Client
    Saturday, June 27, 2009 3:03 PM
  • Yep.  The Web Service Software Factory is for the service side of the app, and the Web Client Software Factory is for the client side.  You'd architect the service using the former, while architecting the client with the latter.  This will allow you to have some great flexibility and a nice abstracted interface between both sides of the app, making it very loosely coupled. 

    In addition, it also provides the possibility (should you need it) of extending the application out beyond the Windows world.  WCF is excellent for interoperability with other OS's, because it's passes XML-based data contracts back and forth. 
    David Morton - http://blog.davemorton.net/ - @davidmmorton - ForumsBrowser, a WPF MSDN Forums Client
    Saturday, June 27, 2009 3:11 PM
  • Thanks a lot David. Will have a look into this and come back to u for advice again if I need anything different..


    Saturday, June 27, 2009 3:20 PM
  • I think that your approach here should be the key concern, not a particular technology choice or implementation.

    I would say that the adding day by day comment means that you need to be able to plug in functionality, provider implementations, or in GoF speak, a strategy and factory pattern.  This allow you to vary implementation details following the same strategy (or interface)  The factory is then able to dynamically instantiate these objects for you.  Take a look at www.dofactory.com for more information.

    The care is in being able to define enough plug in points, and identify what areas that will grow day on day, so that you can define the Interfaces to implement against.

    If you wanted to go completely overboard you could define the whole application in this way, extending implementations for business logic, then implementing plugins for those business logic plugins.  However, I wouldn't recommend that you go that far.

    You scenario isn't rare at all, all software goes through those stages, or if it doesn't evolve, then it was either very visionary, or the cost of extending is not worth the benefit.  The architecture should be the enabler for the software evolution.

    Without knowing what you're actually implementing, it's difficult to be more specific.



    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    Tuesday, June 30, 2009 10:01 PM
  • Hi Guys,

    What David has advised looks good to me. Anyone has a different opinion or has a better suggestion. Anything specific I should take care.

    Thanks Martin I will keep in mind your advise.

    Any comment is appreciated...
    Thursday, July 2, 2009 9:55 AM