The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Application Architecture

Hello everyone.

I'm a recent college grad, and I'm working for a small company developing in VB.Net against SQL Server. Everythings going reasonably well, but the more I do, the more I've realised that a large part of my knowledge is missing.

In college we did programming (of course), systems analysis (UML etc) and software engineering (methodologies, testing and QA etc), all of which were important in and of themselves. To my mind however, there's a large topic in between those that wasn't addressed, and isn't generally addressed in the literature - program design. By that I mean the actual details and trade-offs of developing systems.

We all know that an app should have presentation/business logic/data layers, but there are 101 other things involved in implementing that. Different types of systems merit different designs, the degree of coupling or decoupling of different layers, etc.

This has come up because our app is basically a client running against SQL Server directly. The winforms are riddled with raw ADO.Net, and whilst much of the logic of the app is in modules/classes, it still operates on DataRows and DataTables. I can see these becoming an eventual problem. It's already an issue with a legacy Access/VBA app which has logic code riddled with an ungodly combination of DAO/ADO code, and will have to be rewritten. It would be nice to avoid this problem in the future.

So (at last) the question: what have you used as guides/references/tutorials for this topic?
Sobriquet Send private email
Thursday, September 23, 2004
 
 
The best way to fill in these gaps, IMHO, is to study the "Patterns" literature.  Not just the book by the Gang of Four, but all the Patterns literature.  Each pattern talks about a very particular problem and examines the tradeoffs involved in resolving problem dynamics to produce a solution. 

A great patterns book that touches directly on the problems you've described is Martin Fowler's "Patterns of Enterprise Application Architecture" [ISBN: 0321127420] which I highly recommend.
Bucco
Thursday, September 23, 2004
 
 
The two books Refactoring: Improving the Design of Existing Code and Patterns of Enterprise Application Architecture by Martin Fowler may help.
Justin Kolb Send private email
Thursday, September 23, 2004
 
 
Shalloway and Trott's "Design Patterns Explained" is an excellent introduction to thinking in patterns and gives a concrete example of their application running throughout the book.

"DPE" is an introduction to what's commonly called the "Gang of Four" patterns introduced in the book "Design Patterns" by Gamma, Helm, Johnson, and Vlissides (in case you aren't already aware of the book).

I'd also say hit the comp.* newsgroups, via http://groups.google.com/ or some other means and begin searching through and lurking in the groups that are interesting to you.  You'll pick up all sorts of idioms and lore that way.
Mike Bland Send private email
Thursday, September 23, 2004
 
 
WinForms riddled with raw ADO might be the right tool for the job, depending how small your company is and the probable future of your app. That technique isn't so scalable, but its simpler and therefore less prone to high administration and maintenance costs. If you'll only likely ever has a dozen users, WF+ADO is most likely preferable. Don't let the architecture astronauts scare you!
NetFreak Send private email
Thursday, September 23, 2004
 
 
I picked up Steve McConnell's second edition of "Code Complete" about a week ago. I skipped around to different sections of the book for a few days, but I found enough good advice to dig in and start reading it cover to cover (all 900 pages).

This book is about writing code, and is meant to bridge the gap you're facing. McConnell covers specs and requirements only to say that they're important and beyond the scope of his book. He give a checklist for each, and then a list of a dozen books that cover those topics properly.

The code samples are in C++, Java, and VB. Here it is:

http://www.amazon.com/exec/obidos/ASIN/0735619670
Anon
Thursday, September 23, 2004
 
 
>WinForms riddled with raw ADO might be the right tool for the job, depending how small your company is and the probable future of your app.<

The future of the app is uncertain, but the specs change enough over time that rewriting portions may be likely as market demand becomes apparent. It's a small niche but there's a wide variety of needs within it, so a high degree of maintainability is required.

It's already been the case that two significant parts of functionality have been inadequate and required refactoring. The embedded ado code was the trickiest to disentangle. Not impossible, of course (I'm not _that_ bad), but it could've been a lot better.

It's not out of a need to bolt on an architecture 'just because', but because we've already encountered issues with redesigning to support different methods of connection to the database (web services etc), and the unstructured nature of the code has left a lot spaghetti lying around. Parts of it seem to have grown on their own...
Sobriquet Send private email
Thursday, September 23, 2004
 
 
Seems like you're learning it the hard way, like most of us. The one and only way to feel really concerned about application architecture is by having been bitten previously.
Of course your learning can be greatly accelerated by reading good books, like the ones suggested here. I would also suggest "The Pragmatic Programmer".
Pakter
Thursday, September 23, 2004
 
 
"We all know that an app should have presentation/business logic/data layers"

Question this for a start.  Does you're app really need all these layers?

Rather than asking yourself 'what is the correct way to build this application' try 'what is the simplest architecture that could possibly work?'

Before you read any of those 'Enterprice Programming' or pattern books, I would recommend reading 'The Pragmatic Programmer.'

http://www.pragmaticprogrammer.com/

Will it really have to be rewritten.  Another book you should read is Martin Fowler's Refactoring.
http://www.martinfowler.com/books.html#refactoring

Also take the time to read Joel's Rub a Dub Dub:
http://www.joelonsoftware.com/articles/fog0000000348.html

Ward Cunningham's 'Working the Program' is another interesting read:
http://www.artima.com/intv/clay.html
Ged Byrne Send private email
Friday, September 24, 2004
 
 
>Does you're app really need all these layers?

Rather than asking yourself 'what is the correct way to build this application' try 'what is the simplest architecture that could possibly work?'<

I don't mean to sound dogmatic, but it's becoming increasingly apparent that there's a need to seperate things out. The simplest thing that could possibly work was probably the debauched winforms/ado.net stuff we implemented (am I being too dramatic? :) ). However, the way the software is likely to change in the future seems to demand a more maintainable solution.

I'll be following up on everyone's recommendations - thanks.
Sobriquet Send private email
Saturday, September 25, 2004
 
 
"The simplest thing that could possibly work "


Actually, the suggestion was "The simplest ARCHITECTURE..."



Having ADO calls all over the place doesn't sound like a simple architecture.
Mr. Analogy {Shrinkwrap ISV owner} Send private email
Wednesday, October 06, 2004
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz