Application architecture/design

[Dave]

I have been developing smaller applications in C# for a few years now.
I'm a good enough programmer, and can get an application working
fairly quickly, but I sometimes feel like I'm week on designing a
solid large application from start to finish, that others would be
able to work on with little introduction. I am fine at developing good
classes and understand object oriented design, but sometimes I feel
like I'm missing out on the "magic" of modern .NET programming. In
particular, I don't know when to use things like interfaces,
components, etc. and I really have no idea how to automate things like
file and database access, still using lots of custom SQL code and
custom text reading, coming from a C and VB6 background (i.e. still
getting used to drag and drop coding).

What I'm wondering is if anyone knows of a good tutorial, sample
project, or even those old collections of paper called books, which is
a good resource for learning about high-level application
architecture. I don't need tons of example code, just a few pointers
on how to think about architecture on a large scale, like when
interfaces are used, how to auto-generate lots of code for free, etc.

In the same vein, I've used CASE tools like Rational before, and like
how it auto-generates basically the whole application in Java code
when it's all said and done. Do any similar tools exist for .NET that
are on a student's budget (free, cheap)? The Class Diagram feature is
nice, but hardly allows me the visual documentation I'd like for the
software.

Thanks, and appreciate any pointers on the topic you can give me.

Dave

 

[Chris Mullins [MVP - C#]]

I have been developing smaller applications in C# for a few years now. [...]
but sometimes I feel like I'm missing out on the "magic" of
modern .NET programming. In
particular, I don't know when to use things like interfaces,
components, etc.

What it sounds like you're missing is an OO background. This is something
that I, personally, found very tough to get on my own - it's only through
working with people who were already experts in this field was I able to get
where I am today.

If you understand the mechanics of things like Inheritence and Interfaces,
your best bet is to pick up a book on Design Patterns, and start reading.
For me, this is really when the pieces of the puzzle started to click. Just
go to the local book store, and pick one that seems best to you - they
should have a 1/2 dozen or so books on the topic.

 

[sloan]

To get over the hump, I'll recommend a few things.

Some books, not necessarily C# related:


http://steve.emxsoftware.com/Books+for+the+programmer+beginner

*** The Pragmatic Programmer

*** Pragmatic Unit Testing with NUnit

*** Head First Design Patterns

** Refactoring

Test Driven Development

Domain Driven Design

Agile Software Development: Principles, Patterns, and Practices

Agile Software development with Scrum

**Patterns of Enterprise Application Architecture

Design Patterns

Enterprise Integration Patterns





The ** and *** are ones I have, and also recommend. *** of course means I
really, really like.

Jon Skeets has a sweet new book out as well.





I'm a firm believer in (at least) layered design.

I have a sample here:

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry

please note that I now use

public class OrderCollection : List<BusinessObjects.Order>

{}

instead of having List<BusinessObjects.Order> all over the place.



.........



I also think the Factory Design Pattern is a very basic concept, which can
really clean up your code;

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!126.entry



The last thing is try getting different "Design Pattern" books. Use ebay to
get used copies. Get Java C# VB.Net books, don't be language specific on
design patterns.



Ok, there are some advice tidbits.

Its one drop in the bucket of advice hopefully you'll get.

But I do know what helped me get from your "everyday hack" to something a
little better.



Good luck!

 

[Dave]

To get over the hump, I'll recommend a few things.

Thanks to both of you. From looking at the book descriptions, I think
the keyword "design patterns" applies very well to what I should be
learning next. I thought I had a great OO conceptual understanding,
knowing things like inheritance and polymorphism (went to college,
after all), but I have had no need to really apply a lot of it yet,
and I've been the sole developer at all my companies (meaning no one
to learn from but myself). It took me probably 2 weeks to understand
the singleton pattern, and have already been using it in place of a
bunch of static methods and variables, so more patterns will probably
help me make even better design decisions.

Thanks again!
Dave

 

[Chris Mullins [MVP - C#]]

Patterns will, in general, really help the work you do.

There seem to be some that end up being very popular:
- Factory patterns (concrete / abstract) seem to be the generally applicable
of all the patterns.
- I find myself using the Prototype pattern alot.
- Web developers tend to use the Model-View-Controller pattern quite a bit.
- Command patterns are also very generally applicable.

It's really the common language, and a way of thinking that are very
valuable. Much more so (for me) than the actual patterns themselves.

 

[Kevin Spencer]

It's really the common language, and a way of thinking that are very

valuable. Much more so (for me) than the actual patterns themselves.

I agree, I think, if I understand your meaning by the phrase "a way of
thinking." Patterns are arrived at as a result of analyzing requirements in
the light of certain basic principles of programming (reusability,
extensibility, maintainability, etc), combined with a set of characteristics
of the programming technology (abstraction, inheritance, encapsulation,
etc., for example, in OOP, and various concepts that are abstractions
derived from the consequences of these in practice). There are common
requirements to all programs, including such things as automating tasks,
interfacing with other software and users, managing various kinds of data,
security requirements, etc. Patterns are called patterns because we become
cognizant of shared characteristics that arrange themselves in patterns
across many applications of programming technology. These patterns emerge
more or less naturally with experience, including shared experience (via
communication). Much as assembler language was developed as a result of
seeing common patterns of machine language instructions and combining them
to facilitate the development of software, and as later, higher-level
languages were developed from assembler, and later programming technologies
(such as OOP) were derived from the observation of patterns in procedural
programs, design patterns are a further abstraction which is at a much
higher level, the design level, where we are no longer dealing with the
"bricks and mortar" of software, but the larger picture. We are, in essence,
looking at abstractions of abstractions of abstractions, and applying the
same analytical methods to observe and exploit various patterns that emerge
over time with the accumulation of development experience by many developers
over a long period of time.

So, while understanding and being able to employ a number of common design
patterns is very useful, it is more useful to understand how they were
arrived at, what principles gave rise to them. New patterns constantly
emerge as a result of this, and most patterns are variations on several
basic themes. Rather than concentrating on learning patterns by rote, being
able to improvise a pattern based on these basic themes will prove more
useful in the long run.

This is not to say that being familiar with most commonly-used design
patterns is not important. On the contrary, understanding these abstractions
provides fodder for further analysis, and recognizing these common design
patterns is essential to successfully working in concert with other
developers on various projects.

--
HTH,

Kevin Spencer
Chicken Salad Surgeon
Microsoft MVP

Patterns will, in general, really help the work you do.

There seem to be some that end up being very popular:
- Factory patterns (concrete / abstract) seem to be the generally
applicable of all the patterns.
- I find myself using the Prototype pattern alot.
- Web developers tend to use the Model-View-Controller pattern quite a
bit.
- Command patterns are also very generally applicable.

It's really the common language, and a way of thinking that are very
valuable. Much more so (for me) than the actual patterns themselves.

<snip>>