Coding - Best practices?

[Guest]

Hi,
I have been developing using C# in ASP.Net for about a year now. And have
been a programmer for about 10 years. I have learned many different things
in .NET, but still when I look at sample code fromother programmers I feel
like I am so far behind. I see them usingstuff like Interfaces,
IEnumerables, StringBuilders, etc. I have written several applications in C#
since I started, but I don't ever seem to need or use those more "Advanced"
features.

I have just been assigned a new application to build from scratch.
So this is what I am asking. Where can I find a simple list of what
I should do as I build a new application. I don't really have time
for a 300 page book. What I am looking for is something that says.
"If I were to build a new application I would do A,B,C,etc. I would
use Interfaces for this,because of this, and I would use IEnumerables here
because of this, etc." I know every application is different and you might
not need all of those for every application. But I want to start out
writting this "right" from the beginning. I don't know where people learned
all those advanced things, but I can't seem to find a diffenative web site
that explains the "right" way to do things.

Thanks for all your help. (I know it's alot to ask)

Michael

 

[John Timney \(MVP\)]

but I can't seem to find a diffenative web site that explains the "right"

way to do things.

Thats because there is no right way to do things - only the most appropriate
way for the task that needs to be done.

Very few people know all there is to know about something like .net - they
may know loads about the framework, and then fall foul because their asp.net
app needs javascript and they dont understand that object model or their app
has to touch on a technology they have not come across. Dont worry about it,
even the best developers create crap code sometimes.

I always try to visualise the application working, like cogs in an engine.
Start from the bottom up - whats your inputs, whats your outputs - how do
your inputs get processed by business logic and pass into storage, and how
do your outputs get into the display layer, from storage through your
business layers. read some of the great articles at Scott Guthries blog -
its worth your while.
http://weblogs.asp.net/scottgu/archive/2006/06/22/454436.aspx

Look at how the starter kist are assembled for guidance on how to create
good multi-tiered developments
http://msdn.microsoft.com/msdnmag/issues/03/08/StarterKits/default.aspx

Also look at design patterns - they can save you a lot of work and encourage
best practice.
http://aspnet.4guysfromrolla.com/articles/062503-1.aspx

Regards

John Timney (MVP)
http://www.johntimney.com
http://www.johntimney.com/blog

 

[sloan]

I would read this:
And a reference to read from start to finish, aka, very informative for a
bird's eye view:
*
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

a few times. It gives you the options you could do your code.

You can find an example here:
http://sholliday.spaces.live.com/blog/
5/24/2006
Custom Objects/Collections and Tiered Development


I use custom business entities in my example.
However, I use DataSets to get data to and from the DAL.

Here is an important snipplet from the article. But you should read the
article,....many/several/many times.



Deploying Business Entities
Business entities are used at many different tiers in your application.
Depending on how you implement your business entities, you may need to
deploy them to multiple locations if your application spans physical tiers.
The following list describes how to deploy business entities in different
implementation scenarios:

a.. Deploying Business Entities implemented as typed DataSets. The typed
DataSet class must be accessed by the Data Access Logic Component and by the
calling application. Therefore, the recommendation is to define typed
DataSet classes in a common assembly to be deployed on multiple tiers.
b.. Deploying Business Entities implemented as custom business entity
components. The custom entity class may need to be accessed by the Data
Access Logic Component, depending on how you defined the method signatures
in the Data Access Logic Component. Follow the same recommendation as for
typed DataSets by defining custom entity classes in a common assembly to be
deployed on multiple tiers.
c.. Deploying Business Entities implemented as generic DataSets or XML
strings. Generic DataSets and XML strings do not represent a separate data
type. There are no deployment issues for business entities implemented in
these formats.

 

[sloan]

I would read this:
And a reference to read from start to finish, aka, very informative for a
bird's eye view:
*
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

a few times. It gives you the options you could do your code.

You can find an example here:
http://sholliday.spaces.live.com/blog/
5/24/2006
Custom Objects/Collections and Tiered Development


I use custom business entities in my example.
However, I use DataSets to get data to and from the DAL.

Here is an important snipplet from the article. But you should read the
article,....many/several/many times.



Deploying Business Entities
Business entities are used at many different tiers in your application.
Depending on how you implement your business entities, you may need to
deploy them to multiple locations if your application spans physical tiers.
The following list describes how to deploy business entities in different
implementation scenarios:

a.. Deploying Business Entities implemented as typed DataSets. The typed
DataSet class must be accessed by the Data Access Logic Component and by the
calling application. Therefore, the recommendation is to define typed
DataSet classes in a common assembly to be deployed on multiple tiers.
b.. Deploying Business Entities implemented as custom business entity
components. The custom entity class may need to be accessed by the Data
Access Logic Component, depending on how you defined the method signatures
in the Data Access Logic Component. Follow the same recommendation as for
typed DataSets by defining custom entity classes in a common assembly to be
deployed on multiple tiers.
c.. Deploying Business Entities implemented as generic DataSets or XML
strings. Generic DataSets and XML strings do not represent a separate data
type. There are no deployment issues for business entities implemented in
these formats.


in