The Windows Communication Foundation is one of the fundamental key components of what is now called .Net 3.0.  However, this enhancement comes with a price, a steep learning curve. Without this book by Juval Lowy I doubt many programmers would have the proper guidance necessary to make good design decisions. You see that is what Juval Lowy set out to do in his latest book and I think he did a fabulous job! This book is not for the novice programmer it should be warned, but rather the experienced developer who desires to push his or her skills to the next level.

 

From the very first chapter this book had me hooked. I rarely read technical books all the way through in one sitting however that is exactly what I did with this book. The first chapter starts to explain in plain English what WCF is exactly and from then on the content just gets deeper and deeper.

 

Now it must be said that I am not an software architect by any means however this book helped to give me more of an architectural viewpoint which could only improve my skill set. The design guidelines and best practices are clearly laid out so that anyone with some programming experience should be able to understand. This is not your average computer text which gives a chunk of code and then explains what it does.  There really is nothing average about this writer and book.

 

If you believe that anytime in the near future you will need to understand WCF for your work I would highly recommend picking up a copy of this book. It is not for the feint of heart but the journey is well worth it.

Programming WCF Services

 

 

Recently I have had the pleasure of reading a great book called Accelerated C# 2005 by Trey Nash. I found this book to be both insightful and informative on many levels. Now I am already familiar with C# 2.0 so this book did not necessarily teach me anything particularly new to the language. However the points that Mr. Nash brought out while using C# have helped quite a bit.

 

This book is not your normal C# training manual. Rather, the approach of the author is to take you through the language as if you were an already experienced programmer. I find that approach to be a bit refreshing from the standard explain a bit about a subject, show the code move on approach to writing these types of books.

 

Of all the chapters that I found to be particularly good were the chapters on Generics and Delegates. Generics are still a new subject for me and any new insights I can get on how this is supposed to help is much appreciated! The material in that chapter I believe to be worth the price of the book alone.

 

To give you a listing of what is in store if you should buy this book here is a listing of the table of contents.

 

Chapter 1 – C# Preview

Chapter 2 – C# and the CLR

Chapter 3 – C# Syntax Overview

Chapter 4 – Classes, Structs and Objects

Chapter 5 – Interfaces and Contracts

Chapter 6 – Overloading Operators

Chapter 7 – Exception Handling and Exception Safety

Chapter 8 – Working with Strings

Chapter 9 – Arrays, Collection Types, and Iterators

Chapter 10 – Delegates, Anonymous Functions and Events

Chapter 11 – Generics

Chapter 12 – Threading in C#

Chapter 13 – In Search of Canonical Forms

 

The final chapter of this book, chapter 13, was particularly good in defining some of the best practices when designing and building software. The revelations that this chapter showed me I believe in the long run will help me to be a better developer. Now I do not necessarily agree with all of the best practices outlined in this chapter I will give it some thought when designing software in the future.

 

Personally I would recommend this book for anyone wanting to get into writing C# programs rapidly. This book is however designed for an experienced developer and I would recommend if you are new to programming that you shy away from this book to start and then later pick yourself up a copy.

Accelerated C# 2005 (Accelerated)

Recently I have been reading some really great tutorials on the Validation Application Block by David Hayden on his blog. For those that do not already know David Hayden is one of the few great bloggers out there that actually create well crafted blog posts that actually help us out. He certainly makes me look bad that is for sure, I have to work much harder to get to his level. Perhaps that is osmething I can work on next year? Perhaps, my friends.

This is what he has written about so far.

Validation Application Block in Enterprise Library 3.0 - Using Validation Facade Class - Part I

Validation Application Block in Enterprise Library 3.0 - ValidationFactory Class - Part II

Validation Application Block Ruleset in Enterprise Library 3.0 - Enterprise Library 3.0 Tutorials - Part III

Validation Application Block - Rules in External XML Configuration File - App.Config Web.Config - Enterprise Library 3.0 - Part IV

Validation Application Block - Business Layer and Data Access Layer Integration - Part V

If it were not for David Hayden's efforts I am sure many would be blind as to how to proceed in utilizing this tool that Microsoft has provided. Good work as always David!

I recently came across Matt Hester's blog. Turns out he has some really great performance tips for improving Virtual PC. Some of these tips I would have never thought of had he not blogged about it.

The tips come in a three part series with the first part here.

http://blogs.technet.com/matthewms/archive/2005/09/09/410546.aspx

The second part of the three part series is here.

http://blogs.technet.com/matthewms/archive/2005/09/23/411478.aspx

The third part of the three part series is here.

http://blogs.technet.com/matthewms/archive/2005/10/07/412159.aspx

With those blog posts you should have Virtual PC running quite smoothly and fully optimized so as to not hang during a crucial presentation or developing the next big thing. Hope this helps.

I have recently became a fairly avid user of the CSLA.Net framework by Rocky Lhotka. I find that the framework fills in some of the gaps that I need when I am developing applications. Since I am somewhat new to this framework I am just happy as all get out that there is a new forum where I can ask questions regarding this piece of code.

The forum can be reached here:

http://forums.lhotka.net/

It is powered by Community Server which is also something I am a bit of a fan of as I hope to eventually start a community based programming site with it when I get the time.

So if you have any questions regarding this particular framework and how it may be able to help you or at least clarify some issues that was not covered in the books then this is the place for you.

Just a short note right now I guess.

I got a note from Stan Schultes that our next Sarasotadev meeting will be April 17th, 2006. The meeting details is as follows:

Note the choice of next Monday for our April meeting - it's a bit unusual for us (although we don't have a set day of the month for our regular meetings). Turns out this is the only day the facility is available at no cost to us in the middle two weeks of April (thanks to the Sarasota Community Foundation, and Van & Jody Vangor!).

April 2006 SarasotaDev meeting:

Hands-on sessions - by our own Dave Hayden. Dave's a top-notch, hands-on kind of guy, so these are very practical talks. I've seen both - and they really kick:

• SQL 2005 - native web services, SQL SMO, CLR integration, new XML datatype
• Enterprise Library 2.0 - Applying the Data and Logging Application Blocks

This meeting will be on Mon, Apr 17, 2006 at 6pm. Location: Sarasota Community Foundation, located at 2635 Fruitville Rd., Sarasota, FL 34237 (just west of Tuttle on the north side of Fruitville).

In the SQL 2005 session:

• Learn how to expose and consume your stored procedures as XML web services without using IIS.
• Understand the basics of creating and deploying CLR database objects, like stored procedures, user defined functions, and triggers.
• Use SQL Server Management Objects with C# to create database objects, script objects, and transfer database schema and data.
• Leverage schemas and XQuery with the new XML Datatype for validating and querying XML.

In the Enterprise Library session:
Leverage the application blocks in Enterprise Library 2.0 to more quickly create patterns-based, extensible applications in a consistent manner. Learn about the most popular application blocks (Data Access and Logging) in Enterprise Library 2.0 and how to use them in your applications.

Dave is a Sarasota-based consultant and a Microsoft MVP in C#. Find his excellent tech blog here:  http://davidhayden.com/blog/dave.

Seems like it is going to be a fairly good meeting. Be sure to attend if you have the time.

Just a quick note that since Rocky Lhotka has sent his book off to publishing you can now get the source code for the next version of CSLA.Net 2.0 from his website. This is good news for all those using .Net 2.0. I have not yet had the chance to download and inspect it yet, because I am writing this blog post instead! <G>

You can find the code here.

When the book comes available I am sure there will be a much better explaination of how and why we should use this code framework. Enjoy!

This is a great blog post by one of the members of the SQL Server team explaining when and where SQL Server 2005 Indexes should be used. The topics covered are:

1. How can I find out whether my SQL Indexes are useful?
2. Do I have any tables or indexes that are not uses (or rarely)?
3. What is the cost to benefit of using indexes in SQL Server 2005?
4. Do I have hot spots or index contention?
5. Could I benefit from more or less indexes?

The full blog post can be read here. Again a must read for anyone who wants to gain true performance from their SQL Server.

Today I attended a live webcast on DotNetNuke hosted by Stan Schultes and Russ Fustino and the topic of security in the DNN framework came up. I originally was going to post a article on the subject of how to encrypt a connection string in ASP.Net when I came across this resource guide. This lists a series of how to guides on the best practices for both .Net versions. If you have not already done so, you should check it out here.

It can be found here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/securityhowtosindex.asp

This should answer any question you may have regarding the following subjects:

• Authentication and Authorization
• Code Access Security
• Code Review
• Communication Security
• Configuration
• Cryptography
• Deployment Review
• Impersonation and Delegation
• Input and Data Validation
• Patching and Upgrading
• SQL Server 2000
• Threat Modeling
• Web Services
• Etc.

Hopes this helps someone out there who may stumble across my blog looking for information on these subjects. Eventually I hope to write an article about each of these particular areas when I have the time to do so.

 

For many developers out in the .Net community it was ASP.Net that initially drove them to switch from some other platform. This was most likely due to the much enhanced programming model that ASP.Net provided and the improvements in performance that were promised and delivered. However, although the ASP.Net platform is a highly robust and scalable system you should still be aware of a few tricks of the trade that may help you increase your performance on your web application.

 

During my years of working with .Net I have learned many things on how to properly deal with certain situations that arise. Hopefully, you will find this information useful.

 

Best Practice #1

It is usually a good idea to set the SmartNavigation property to true on most pages.

The reasoning:

This reduces or eliminates screen flickering during postbacks to the server. Furthermore the scroll position will be preserved.

 

Best Practice #2

Enable the ability for multiple postbacks when using AutoPostback controls by using a user interface device such as a button.

The reasoning:

If the user has disabled Javascript controls in their browser then there is no way for the user to submit the form unless you provide a button or other user interface device.

 

Best Practice #3

It is preferred to use the Server.HtmlEncode method when displaying data taken from the database to an HTML control or Web control.

The reasoning:

This makes sure that the special characters are displayed in the correct manner and prevents cross side scripting attacks.

 

Best Practice #4

It is always best to validate input on the client side by using a validator control. Also, make sure you also validate all data on the server side as well as unforeseen security vulnerabilities can put your server at risk.

The reasoning:

Validation of all data is a best practice in all situations. This ensures a consistent database and data integrity and the integrity of your website.

Best Practice #5

It is usually a best practice to make sure the client is still connected during a time consuming task. This can be accomplished using the Response.IsClientConnected method during a known time consuming task.

The reasoning:

This method allows you to check to see if the client is still connected to the server. If the client is no longer connected you can then use the Response.End method to end the session and free up resources.

 

Best Practices #6

It is usually a good practice to avoid the use of hidden fields in order to store data between page postbacks.

The reasoning:

There are few very good reasons for storing potentially sensitive information using hidden fields. These do not store data in an encrypted manner or can store any significant amounts of data.

 

Best Practice #7

It is usually a good practice to store data taken from either files or a database in the ASP.Net cache object if the data does not change much over a period of time and can be shared with multiple users on the webpage.

The reasoning:

By storing and caching the data taken from a file or database you increase the performance and scalability of your application.

 

Best Practice #8

It is a best practice to use a Global error handler in the Global.asax file of your application.

The reasoning:

This allows you to recover properly from unexpected exceptions in the current application. Also this may allow you to implement a common error recovery mechanism for your web application.

 

Best Practice #9

It is always best to never use the Off attribute when setting the <custom errors> attribute in the web.config file of your application when it resides on a production server viewable by the outside.

The reasoning:

Doing this will enable unauthorized visitors to view potentially sensitive information about your application thereby increasing the security risk that  your website can be attacked from outside visitors.

Best Practice #10

It is always best to set your application tracing in the web.config file rather than using the @Page directive on individual aspx pages.

The reasoning:

This allows you to enable application level tracing for the entire application rather than for each individual page of  your website.

It can hardly be said that any serious programmer has had to deal with database programming at least some time in their careers. So it would be logical then to make sure your connection to these underlying databases are as efficient as possible. Hopefully I will share some of the best practices I have learned in dealing with ADO.Net programming. These techniques were learned from a variety of sources, many of them I can not remember sorry. Hopefully you will find them equally as useful as I do.

 

Best Practice #1

Always use native .Net data providers.

The reasoning:

It has been proven by using the native .Net data providers always perform better and allow you to take advantage of both the .Net framework and the full power of the underlying database.

 

Best Practice #2

Always use a config file to store your connection strings. Also it might be a good idea to encrypt these connection strings especially if stored in a dubious location.

The Reasoning:

It is always best to store data that might change in a location outside of your application where you can easily update the connection strings. Also encrypting the connection strings is always a good idea from a security standpoint.

 

Best Practice #3

It is always best to use Windows authentication mode when connecting to your SQL Server database, this really applies mostly to Windows Forms applications.

The Reasoning:

Windows authentication is always much safer as the username and password do not pass over the wire.

 

Best Practice #4

Always use an asynchronous delegate when establishing a connection from a Windows Forms application.

The Reasoning:

This will prevent the user interface from seeming to seizing up as the application attempts to connect to the underlying database.

 

Best Practice #5

Prefer to use the sorting methods on the SQL Server such as the ORDER BY, HAVING and GROUP BY statements.

The Reasoning:

By performing the sorting on the server side as opposed to the client side you save time because the server can perform the work faster.

 

Best Practice #6

You should always try to limit the number of rows in a resultset. This can be performed typically by using the TOP keyword or other similar methods.

The Reasoning:

By limiting the amount of information you send through the wire you make the application seem faster and this also allows for a more scaleable design.

 

Best Practice #7

It is always best to use the CommandBehavior.CloseConnection enumerated value when you invoke the ExecuteReader method of a Command object.

The reasoning:

This allows for better connection pooling as the connections that are opened are returned quickly.

 

Best Practice #8

It is always best to cancel before closing a DataReader object if you are finished reading any more rows.

The reasoning:

The close method of the DataReader class continues to read all remaining rows before it finally closes the object. This is a wasteful use of resources.

 

Best Practice #9

It is always best to use a parameterized command over dynamic SQL queries.

The reasoning:

This will improve performance and reduce the a SQL injection attack while also making your code much more easier to maintain.

 

Best Practice #10

It is always best to access tables through views and stored procedures over other methods like dynamic SQL queries.

The reasoning:

The stored procedures and views do not add any overhead to a SQL server while providing some level of indirection which allow you to change the structure of the database table without drastically affecting your client code.

 

Best Practice #11

It is always best to implement some sort of resultset pagination when dealing with results of 50 or more rows.

The reasoning:

Although not an easy task in most cases using this technique you can increase performance on both your server database and your client application as less overhead and network traffic is taking place at any one time.

Best Practice #12

It is always best to close a transaction as quickly as possible.

The reasoning:

When a transaction occurs one or more rows are locked which means other users or applications can not access them. By using as short of a transaction as possible you ensure the scalability and stability of your application.

 

Best Practice #13

Never rely on the default behavior of the DataAdapter object for managing concurrency issues with your database.

The reasoning:

The DataAdapter object relies on the underlying which will leave itself in an inconsistent state if an update occurs, this is because ADO.Net will only throw an exception and not resolve the actual conflict at hand.

 

Best Practice #14

It is usually best to implement a timestamp field when you are using optimistic concurrency.

The reasoning:

This will allow to more easily detect when another user has updated the database.

SQL Server is a very powerful tool when used properly. It can also come to a screeching halt if left to rot with no maintenance and poor planning. While the program itself is highly scalable it is still subject to performance bottlenecks and slow response times caused by inattentive administrators and developers. I have learned much about SQL Server 2000 in the past year many of those are the best practices used by other developers and senior administrators. I hope to share that information with you now so that those just starting out can learn from what I have learned.

 

Best Practice #1

Download and install and actually use the SQL Server Best Practices Analyzer tool provided by Microsoft.

The Reasoning:

This tool will scan your databases for any code or implementation issues that do not conform to Microsoft Best Practices standards. This should be the starting point on any existing or currently in production database you may have. Now you can take each recommendation with a grain of salt as the tool is probably not aware of every situation a developer may face. So therefore it is always up to the developer or administrator to decide which practices to put into place.

 

Best Practice #2

Never start the name of any stored procedure with the SP prefix.

The reasoning:

All system stored procedures start with the SP prefix. Naming your stored procedures in this manner will cause potential clashes as service packs are released potentially with the exact same naming as your previous stored procedure. This is highly unwise.

 

Best Practice #3

Apply the latest service packs and security packs

The reasoning:

With so many potential threats against a database keeping your system up to date will ensure data integrity. Keeping data integrity should be the duty of anyone either developing on the database or administrating the database.

 

Best Practice #4

Keep your result sets that you return from your database as small as possible.

The Reasoning:

Not only does this greatly improve performance but it makes the database much more scalable and better able to handle more concurrent users.

Best Practice #5

Avoid the Insert statement when performing bulk inserts into your database.

The reasoning:

The DTS or BCP utilities are far better for inserting information in bulk into SQL Server. These utilities are far more flexible then the SQL Bulk Insert statements you may want to use.

 

Best Practice #6

Keep your stored procedures as small as possible.

The reasoning:

If two users are accessing the same stored procedure at the same time then two query plans will be stored in the cache. It is far better to have smaller stored procedures call other stored procedures then one very large stored procedure. This practice makes maintaining the code a bit easier as well.

 

Best Practice #7

Analyze all your query plans using the SQL Query Analyzer to make sure they are performing at optimum speed.

The reasoning:

Getting to know how to use the SQL Query Analyzer is one of the best things any serious developer can do to improve performance in an application. Using this tool you can see where are the bottlenecks in your code and thereby increase performance by altering indexes or even re-writing stored procedures.

 

Best Practice #8

Always code for multiple user scenarios

The Reasoning:

If  you plan ahead and design your database with the proper data concurrency issues already solved then the future up keep of your database will be minimized. While the upfront costs associated with this might be higher the potential payback can be great as a application changes in its lifecycle.

 

Best Practice #9

Use User Defined Functions wisely and sparsely.

The reasoning:

It is far better to use stored procedures in your code then User Defined Functions. While using these functions may at times increase the performance of  your database it is more likely that they will be converted into stored procedures in the future as the database matures.

 

Best Practice #10

Do not use Select * in your query design. Instead make sure you use the proper column names in the query.

The reasoning:

Using the proper column names decreases network traffic, takes less load on the database and hence can greatly improve performance.

Best Practice #11

Avoid the use of nullable columns.

The reasoning:

The use of the nullable column consumes an extra byte on each column used. Furthermore when querying data there is much more overhead with nullable columns. Try to use alternative methods when designing a database to allow for a representation of zero data in the column.

 

Best Practice #12

Analyze and avoid deadlocks at all costs.

The reasoning:

It is far better to access your data the same way each time you query  your database. Doing otherwise will create a deadlock situation when one process takes control while another process is fighting for the same control over the objects. This can greatly tie up resources and can cause your program to crash if not taken into account. Always try to avoid a deadlock before one occurs. Use hints on your queries to make sure they are performing the way you want them to.

 

Best Practice #13

Create indexes on highly selective columns.

The reasoning:

It is far better to create an index on a highly selective column as this will increase the performance of your database design.

 

Best Practice #14

Avoid using cursors or use cursors very wisely.

The reasoning:

Cursors consume far too much database resources to be considered a viable option in most cases. There are other options available and proper design of the program will account for this. However when you need to use cursors, when there is no other alternative, then use them very wisely and make sure  you research any issues with cursors before implementing them in production. Test the database under a realistic load scenario.

 

Best Practice #15

Always make sure your database is as normalized as possible.

The Reasoning:

This is database design 101 here folks. If you have an un-normalized database design make sure to normalize the database design to the 3^rd normal form as this is considered to be the standard. The only excuse for a non normalized design is for performance reasons. However my argument with this should be that denormalizing a database schema should be considered a last resort.

Best Practice #16

Remember to SET_NOCOUNT_ON at the beginning of your SQL bataches, stored procedures, triggers, etc.

The reasoning:

Doing this will increase performance by reducing network traffic. Setting SET_NOCOUNT_ON suppresses the messages regarding how many rows are affected after executing INSERT,UPDATE, SELECT and DELETE statements.

 

Best Practice #17

Avoid the use of the TEXT and NTEXT datatypes in your database design.

The reasoning:

There are far too many issues associated with TEXT and NTEXT datatypes for them to be of any great use to you. Instead it is far better to use the varchar and char datatypes instead.

 

Best Practice #18

Do not store BLOBS in your database.

The reasoning:

A database was not designed to stored datafiles or images. Instead it is far better to store the location of these files inside the database and let the operating system handle the file I/O for you. This is far better way to store large data files in your database.

 

Best Practice #19

Always perform referential integrity checks and data validations using constraints such as the foreign key and check constraints.

The reasoning:

It is far better to use constraints as opposed to triggers when performing referential integrity checks. The use of triggers should only be used to perform custom data validation that can not be performed using constraints.

 

Best Practice #20

Make sure all your stored procedures return a value indicating their status.

The reasoning:

Make sure you standardize on the return types your stored procedures should return indicating either success or failure. Doing this will increase the maintainability of the code and make programming against it much easier. This is especially ture if everyone understands and follows the standards.

 

Best Practice #21

Make sure you start each clause of your SQL statement on a new line.

The reasoning:

This makes the SQL code much more readable. You should consider this especially if you are in a team environment or a visiting consultant.

Best Practice #22

It is always best to avoid the use of column numbers in the ORDER BY clause.

The Reasoning:

Using some column numbers does not increase the performance of your query by any significant amount and also this makes  your code harder to read especially in large queries.

Stings are a difficult and sometimes touchy subject when it comes to programming. In the C language improper use of strings can crash your whole system. Even some professors in Colleges and Universities do not teach their students how the native string functions in the C language work simply because they consider them far too dangerous for students to learn.

 

I will try to cover the best practices of handling strings that I have picked up over the years in the hope that it will either improve your performance or stop you from making some of the blunders I have made in the past.

 

Best Practice #1

Pertains to Visual Basic

It is always best to use the & to concatenate strings instead of the + operator.

The reasoning:

The + operator was only kept for historical reasons. It is far better to use the & operator because it make your code easier for other programmers to read it.

 

Best Practice #2

Use a char variable instead of a string variable only if you are certain you need to store only one character.

The reasoning:

The char variable takes up less space than a 1 character string.

 

Best Practice #3

Always explicitly initialize string variables to a zero length string.

The reasoning:

By explicitly initializing a string variable you avoid NullReferenceException errors when you reference the string.

 

Best Practice #4

You should always return an empty string when defining a method or property when the end result string has no characters.

The reasoning:

This simplifies the task of the calling code which will then not have to test for a null.

 

Best Practice #5

Never use language specific string functions.

The reasoning:

Language specific functions always perform worse their .Net native methods.

 

Best Practice #6

When checking for empty strings compare the length property with zero rather than with a String.Empty

The reasoning:

Checking the string length for zero has better performance then with the String.Empty method.

 

Best Practice #7

When comparing two strings use the String.Compare method to compare strings in case insensitive mode.

The reasoning:

The ToUpper and ToLower methods both create a new string and by doing this affect the memory heap. Also the Compare static method is far faster then using the ToUpper and ToLower string functions because there is no need to create new strings and then compare them.

 

Best Practice #8

Always use the Regex type to validate string input by the user or read from an external source such as the file system.

The Reasoning:

You should always validate input from any source that could affect the security or performance of your application.

 

Best Practice #9

Never hard code any value or variable that may change once the application goes into production. Instead store those values in a config file that your program can use to update those values dynamically.

The reasoning:

You simply do not want to have to update the entire program simply because something has changed in the production environment. This is a headache you simply want to avoid at all costs.

 

Best Practice #10

Avoid hard coded strings that may appear in the user interface. Instead use a resource file instead.

The reasoning:

You always want to avoid any programming that would make it difficult in the future to update your application.