Nested Transactions

SQL Server allows you to nest transactions. Basically, this feature means that a new transaction can start even though the previous one is not complete. Transact-SQL allows you to nest transaction operations by issuing nested BEGIN TRAN commands. The @@TRANCOUNT automatic variable can be queried to determine the level of nesting - 0 indicates no nesting , 1 indicates nesting one level deep, and so fourth.

A COMMIT issued against any transaction except the outermost one doesn't commit any changes to disk - it merely decrements the@@TRANCOUNT automatic variable. A ROLLBACK, on the other hand, works regardless of the level at which it is issued, but rolls back all transactions, regardless of the nesting level. Though this is counterintuitive, there's a very good reason for it. If a nested COMMIT actually wrote changes permanently to disk, an outer ROLLBACK wouldn't be able to reverse those changes since they would already be recorded permanently.

When you explicitly begin a transaction, the @@TRANCOUNT automatic variable count increases from 0 to 1; when you COMMIT, the count decreases by one; when you ROLLBACK, the count is reduced to 0. As you see, the behavior of COMMIT and ROLLBACK is not symmetric. If you nest transactions, COMMIT always decreases the nesting level by 1, as you can see illustrated in Figure 1. The ROLLBACK command, on the other hand, rolls back the entire transaction, illustrated in Figure 2. This asymmetry between COMMIT and ROLLBACK is the key to handling errors in nested transactions.

Figure 1: A COMMIT always balances a BEGIN TRANSACTION by reducing the transaction count by one.

Figure 2: A single ROLLBACK always rolls back the entire transaction.

As you can see from Figure 1 and Figure 2, you can nest transactions and use the @@TRANCOUNT automatic variable to detect the level. You also learned that COMMIT and ROLLBACK do not behave symmetrically; COMMIT just decreases the value of @@TRANCOUNT, while ROLLBACK resets it to 0. The implication is that a transaction is never fully committed until the last COMMIT is issued. No matter how deeply you nest a set of transactions, only the last COMMIT has any effect.

Reference: http://www.codeproject.com/KB/database/sqlservertransactions.aspx

Note: All this content is from internet sources.

Association, Aggregation, Composition

Association

When we have only one relationship between objects, that is called Association. Aggregation and Composition both are specialized form of Association. Composition is again specialize form of Aggregation.

Association is a relationship where all object have their own lifecycle and there is no owner. Let’s take an example of Teacher and Student. Multiple students can associate with single teacher and single student can associate with multiple teachers but there is no ownership between the objects and both have their own lifecycle. Both can create and delete independently.

Aggregation

Aggregation is a specialize form of Association where all object have their own lifecycle but there is ownership and child object can not belongs to another parent object. Let’s take an example of Department and teacher. A single teacher can not belongs to multiple departments, but if we delete the department teacher object will not destroy. We can think about “has-a” relationship.

Composition

Composition is again specialize form of Aggregation and we can call this as a “death” relationship. It is a strong type of Aggregation. Child object dose not have their lifecycle and if parent object deletes all child object will also be deleted. Let’s take again an example of relationship between House and rooms. House can contain multiple rooms there is no independent life of room and any room can not belongs to two different house if we delete the house room will automatically delete. Let’s take another example relationship between Questions and options. Single questions can have multiple options and option can not belong to multiple questions. If we delete questions options will automatically delete.

Another example, a university owns various departments (e.g., chemistry) , and each department has a number of professors. If the university closes, the departments will no longer exist, but the professors in those departments will. Therefore, a University can be seen as a composition of departments, whereas departments have an aggregation of professors.

Reference: http://geekswithblogs.net/mahesh/archive/2006/11/03/95960.aspx

The Four Tenets of SOA

John Evdemon has the following to say of SOA in his article with the same title how true is this statement.

'SOA has become a well-known and somewhat divisive acronym. If one asks two people to define SOA one is likely to receive two very different, possibly conflicting, answers. In many ways SOA is a bit like John Godfrey Saxe’s poem about the blind men and the elephant – each of the men describes the elephant a bit differently because each of them are influenced by their individual experiences (e.g. the man touching the trunk believes it’s a snake while the one touching a tusk believes it’s a spear). Mr. Saxe’s elephant is much easier to describe because it exists as a physical entity - SOA, however, is a much harder to describe since design philosophies are not available as a physical manifestation. '

e above is just the begining of wonderful article and it is quite difficult to reproduce the same.

The SOA tenets originally appeared back in 2004 when Don Box published an article on MSDN called "A Guide to developing and Running Connected Systems with Indigo" (Indigo is what's known today as Windows Communication Foundation or WCF for short).

Don continues to define and explain he following 4 tenets:

• Boundaries are explicit
• Services are autonomous
• Services share schema and contract, not class
• Service compatibility is determined based on policy
  

The interesting fact is that Microsoft's Harry Pierson (a.k.a. DevHawk) suggests that Microsoft's own 4 tenets for SOA should be retired because, well, they are, in Harry's opinion, useless - at least they are not useful anymore.

He says, "I would say that the tenets' job is done and it's time to retire them. Once you accept the service-oriented paradigm, what further guidance do the tenets provide? Not much, if any"

If this statement surprises you read the article: Retire Microsoft's Four SOA tenets?

A Performance Comparison of Windows Communication Foundation

Windows Communication Foundation (WCF) is a distributed communication technology that ships as part of the .NET Framework 3.0. The following article concentrates on comparing the performance of WCF with existing .NET distributed communication technologies.

A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies

Here is the conclusion taken from the above article:
To summarize the results, WCF is 25%—50% faster than ASP.NET Web Services, and approximately 25% faster than .NET Remoting. Comparison with .NET Enterprise Service is load dependant, as in one case WCF is nearly 100% faster but in another scenario it is nearly 25% slower. For WSE 2.0/3.0 implementations, migrating them to WCF will obviously provide the most significant performance gains of almost 4x.

WCF vs Remoting

The following blog does the comparison between WCF and Remoting.

WCF vs. Remoting (with DataSet)- performance comparison

Here is the conclusion taken from the above article:
Sending DataSet with .NET Remoting is faster than sending it with WCF. Maybe there is some other way to improve the WCF in case of sending DatSet but I haven't found it yet. I'll post the test project somewhere (maybe on codeproject) so it could be examined.

He further refined his test in the following blog

WCF vs Remoting - adjustments to my results

Here is the conclusion taken from above article:

The WCF and .NET Remoting are really comparable in performance. The differences are so small (measuring client latency) that it does not matter which one is a bit faster. WCF though has much better server throughput than .NET Remoting and WCF does much more than.

Delegate and Events

People often find it difficult to see the difference between events and delegates. C# doesn't help matters by allowing you to declare field-like events which are automatically backed by a delegate variable of the same name. In this posting, I will just touch the surface so that it will tickle you to go ahead read the references that are given at the end of the posting.

In his blog Roy Osherove has the following comments:

Here’s how you define a delegate in a class:

public class SampleDelegate
{
public delegate void DoSomethingDelegate(int num1, int num2);
public DoSomethingDelegate MyDelegateCallback;
}

And here’s how you declare an event of this delegate:

public class SampleEvent
{
public delegate void DomSomethingDelegate(int num1, int num2);
public event DomSomethingDelegate MyDelegateCallback;
}

Notice that syntactically, the only difference is that you place an “event” keyword before the delegate variable declaration.

So what’s the “event” keyword adding to this?
Well, to understand this, consider SampleDelegate in the code above. If you are using this class, as a client you could set it’s delegate variable like this:

SampleDelegate c = new SampleDelegate();
c.MyDelegateCallback += new SampleDelegate.DoSomethingDelegate(this.Calculate);

This simple code adds a new target to the delegate’s invocation list and the same code will work for SampleEvent.

SampleEvent c = new SampleEvent();
c.MyDelegateCallback += new SampleEvent.DomSomethingDelegate(this.Calculate);

There is no difference what so ever so far. But consider this code which, instead of adding a new target to the delegate’s Invocation list, simply sets the delegate to a new delegate:

SampleDelegate c = new SampleDelegate();
c.MyDelegateCallback = new SampleDelegate.DoSomethingDelegate(this.Calculate);

This piece of code will work just fine with SampleDelegate, but if you try to use it on SampleEvent, where there is the event keyword declared, youwould get a compilation error.

In essence, declaring the event keyword prevents any of the delegate’s users from setting it to null. Why is this important? Image that as a client you would add to the delegates invocation list a callback to one of my class’s functions. So would other clients. All is well and good. Now suppose someone, instead of using the “+=”, is simply setting the delegate to a new callback by using simply “=”. They basically just threw the old delegate and its invocation list down the drain and created a whole new delegate with a single item in its invocation list. All the other clients will not receive their callbacks when the time comes. It is this kind of situation that having the “event” keyword is aiming to solve.

In conclusion: an event declaration adds a layer of protection on the delegate instance. This protection prevents clients of the delegate from resetting the delegate and its invocation list, and only allows adding or removing targets from the invocation list.

For a deeper insight refer to the Jon Skeet's article - Delegates and events. Also Julien Couvreur's article C# events vs. delegates is worth reading.

Humor hour - Something to make you smile!

Kids Are Quick
____________________________________
TEACHER: Maria, go to the map and find North America.
MARIA: Here it is..
TEACHER: Correct. Now class, who discovered America?
CLASS: Maria.
____________________________________
TEACHER: John, why are you doing your math multiplication on the floor?
JOHN: You told me to do it without using tables.
______________________________ ____________
TEACHER: Glenn, how do you spell 'crocodile?'
GLENN: K-R-O-K-O-D-I-A-L'
TEACHER: No, that's wrong
GLENN: Maybe it is wrong, but you asked me how I spell it.
____________________________________________
TEACHER: Donald, what is the chemical formula for water?
DONALD: H I J K L M N O.
TEACHER: What are you talking about?
DONALD: Yesterday you said it's H to O.
__________________________________
TEACHER: Winnie, name one important thing we have today that wedidn't have ten years ago.
WINNIE: Me!
__________________________________________
TEACHER: Glen, why do you always get so dirty?
GLEN: Well, I'm a lot closer to the ground than you are.
_______________________________________
TEACHER: Millie, give me a sentence starting with 'I.'
MILLIE: I is..TEACHER: No, Millie..... Always say, 'I am.'
MILLIE: All right.... 'I am the ninth letter of the alphabet.'
_________________________________
TEACHER: George Washington not only chopped down his father's cherry tree, but also admitted it. Now, Louie, do you know why his father didn't punish him?
LOUIS: Because George still had the axe in his hand.
______________________________________
TEACHER: Now, Simon, tell me frankly, do you say prayers before eating?
SIMON: No sir, I don't have to, my Mom is a good cook.
______________________________
TEACHER: Clyde, your composition on 'My Dog' is exactly the same as your brother's. Did you copy his?
CLYDE: No, sir. It's the same dog.
___________________________________
TEACHER: Harold, what do you call a person who keeps on talking when people are no longer interested?
HAROLD: A teacher
__________________________________

Five Steps to Improved Performance

With the limited time available for tuning, and the extent of improvement that is typically needed, it is vital to focus on those areas that have the highest potential for payoff, rather than to expend effort on improvements that have a negligible overall effect. You may find yourself spending weeks or even months tuning the software without seeing significant improvements. It is usually caused by speculation on the cause of performance problems and a random approach to improvements. The steps below allow you to quickly identify problems, focus your effort on the areas of the software that have the greatest potential for improvement and estimate the relative payoff for potential improvements.

Step 1: Figure Out Where You Need to Be

You should define precise, quantitative, measurable performance objectives. You can express performance objectives in several ways, including response time, throughput, or constraints on resource usage. Some examples are: “The response time for a transaction should be one second or less with up to 1,000 users.” or “CPU utilization should be less than 65% for a peak load of 2,000 events per second.”

When defining performance objectives, don’t forget that your needs may change over the product’s lifetime. For example, your current performance objective may be to process 10,000 events per second. However, in two years, you may need to be able to process 30,000 events per second. It is a good idea to consider future uses of your software so that you can anticipate these changes and build in the necessary scalability.

Step 2: Determine Where You Are Now

Begin by quantifying the problems and identifying their causes. Which uses of the software are causing problems? Typically, these are the most frequent uses. If you don’t have good documentation (like UML sequence diagrams) for these uses, it’s a good idea to do this now. Then, identify the workloads (transaction or customer-call volumes, event arrival rates, and so on) that are causing problems.

Focusing on the architecture provides more and potentially greater options for performance improvement than tuning. By focusing on the architecture, you can identify opportunities for changing what the software does.

Now you will later need to take measurements of the scenarios under operational conditions. This will allow you to understand the system performance parameters such as CPU utilization, I/O rates and average service time, network utilization, message size, and so on. This, in turn, will allow you to identify the bottleneck(s)—the device(s) with the highest utilization. Then, profile the processing steps in the performance scenarios to identify the “hot spots.” The overall impact of improvements gained from addressing these hot spots will be far greater than that of random improvements.

Step 3: Decide Whether You Can Achieve Your Objectives

Before you dive into tuning your software, it’s a good idea to stop and see if you can actually achieve your objectives by tuning. If the difference between where you are now and where you need to be is small, then tuning will probably help. You may even be able to achieve your performance objectives without making changes to the code by tuning operating system parameters, network configuration, file placements, and so on. If not, you’ll need to tune the software.

Performance remedies range from low-cost (and, usually, low-payoff) automatic optimization options (e.g., compiler optimizations) to high-cost (and, potentially, high- payoff) software refactoring or re-creation. Intermediate options are to optimize algorithms and data structures and/or modify program code to use more efficient constructs.

Once you’ve identified the hot spots, some simple calculations will help you decide if you can meet your performance objectives by tuning the software. If not, you may need to explore other alternatives, such as adding more processors. If it is, then you can proceed with confidence as you tune the software. You might also create software models that depict the end-to-end processing steps for performance scenarios. The models will help you quantify the effects of more complex solutions, particularly those that involve contention for resources.

Step 4: Develop a Plan for Achieving Your Objectives

Once you have identified potential remedies, you can rank them based on their payoff. Then apply them starting with those that have the highest payoff. You determine the quantitative performance improvement by estimating the new resource requirements.

Create a list of options that compares the performance improvement versus the costs to determine the best candidates. Note that you may not always choose the option with the best performance improvement because other factors may make it less desirable. For example, the option with the best performance improvement may be risky because it uses an unfamiliar new technology. Or, a change with a high performance payoff may negatively impact another important quality such as maintainability or reliability. You may elect to correct problems with hardware. Be sure to use the models to evaluate this option too. Sometimes the problem is caused by software and no amount of hardware will correct it.

Step 5: Conduct an Economic Analysis of the Project

Upon completion, gather data on the time and cost for the performance analysis, time and for software changes (include coding and testing), hardware costs if applicable, software distribution costs when applicable, and all other costs of the project. Then gather data on the effect of the improvements. These may include savings due to deferred hardware upgrades, staff savings (ie. If fewer staff members are required to use the software), revenue increases (ie. when you can increase the number of orders processed), and so on. It is also a good idea to review the changes made to see if they could have been predicted earlier in the software’s life. If your problems could have been prevented, compare the costs and benefits of detecting and correctingproblems earlier versus detecting them after problems occurred. Then use this data on your next project to determine whether it is worthwhile to spend a little more effort during development to prevent problems.

Cost-Benefit Analysis

The process involves, whether explicitly or implicitly, weighing the total expected costs against the total expected benefits of one or more actions in order to choose the best or most profitable option. Using this process can provide a high payoff for a relatively small cost.

An Ounce of Prevention

Once you run into trouble, tuning the software is likely to be your only choice. However, it’s important to realize that a tuned system will rarely, if ever, exhibit the level of performance that you could have achieved by designing in performance from the beginning. The key to achieving optimum performance is to adopt a proactive approach to performance management that anticipates potential performance problems and includes techniques for identifying and responding to those problems early in the process. With a proactive approach, you produce software that meets performance objectives and is delivered on time and within budget, and avoid the project crises brought about by the need for tuning at the end of the project.

Note: This content is cut down version of the following:
Five Steps to Improved Performance by Lloyd G. Williams and Connie U. Smith

Databinding in WPF

Data binding in the user interface layer is nothing new. It has been around for quite some time, in various UI platforms, both for desktop and Web applications. The basic idea is that you "bind" the visual elements (controls) in a user interface to the data objects they are meant to display. The binding infrastructure then manages the data interactions from then on, so that modifications to the UI controls are reflected in the data objects, and vice versa. The major benefit of using data binding is that it reduces the amount of code the application developer needs to write.

The architects of some earlier UI platforms have done a good job integrating data binding with the rest of their framework. WPF's architects have done an amazing job integrating data binding with all aspects of their framework. Data binding in WPF is ubiquitous and seamless. It is so powerful and flexible that it literally forces you to change the way you think about designing and developing user interfaces.

With one simple API you can bind to domain/business objects, XML data, visual elements, ADO.NET data containers, collections, and basically anything else you can think of. You can use value converters to execute arbitrary data manipulation operations when bound values are passed back and forth. You can perform data validation by creating custom validation rules and applying them to a binding. The list goes on. Data binding in WPF is really a huge step forward.

A comparison

A developer typically creates a class to represent an entity (table) in the database, whereby CRUD operations are performed by calling methods on the objects, e.g; for class Employee, objEmployee.Save(), objEmployee.Load(), objEmployee.Update(), objEmployee.Delete() etc. Also, everytime the values in the object change, the developer has to manually write code to update each of the UI elements that display the values stored in the object's members. The same holds true when the values on the UI change. With WPF, you can lessen your code greatly by binding the object directly with the UI (each of object's members data-bound to individual UI elements) using XAML syntax. Adnan Farooq Hashmi does a very good comparison between the older approaches and the new approach in his blog.

The world of data binding

Josh Smith explores the world of data binding, and how it is put to use in the WPF Horse Race demo application in his article. His article will tickle your taste buds and you will desire more and for this you can turn on to the msdn article by Shawn Wildermuth where he gives a detailed explantion of the same. I guess that the wpf is incomplete with out the mention of binding converters and Amit has posted the following artcle WPF Binding Converter Best Practices.

Binding with LINQ to SQL

LINQ to SQL is an object-relational mapper (ORM) tool that generates business objects that match your database structure. When using LINQ to bind in a WPF interface, LINQ object already define the INotifyPropertyChanged interface, which means change notification is possible for any values edited from another process. Brian Mains has touche well on this topic in his good article 'WPF Data Binding, With LINQ'.

The Allure of Distributed Objects

This is a very interesting section taken from 'Patterns of Enterprise Application Architecture' by Martin Fowler. It throws light on on how we at times fall into the Allure of Distributed Objects. A careful thought has to be given when designing such solutions.

There is a recurring presentation that I used to see two or three times a year during design reviews. Proudly the system architect of a new OO system lays out his plan for a new distributed object system—let's pretend it's a some kind of ordering system. He shows me a design with separate remote objects for customers, orders, products, and deliveries. Each one is a separate component that can be placed on a separate processing node.

Distribute an application by putting different components on different nodes.
I ask, "Why do you do this?"
"Performance, of course," the architect replies, looking at me a little oddly. "We can run each component on a separate box. If one component gets too busy we add extra boxes for it so we can load-balance our application." The look is now curious as if he wonders if I really know anything about real distributed object stuff at all.

Meanwhile I'm faced with an interesting dilemma. Do I just say out and out that this design sucks like an inverted hurricane and get shown the door immediately? Or do I slowly try to show my client the light? The latter is more remunerative but much tougher since the client is usually very pleased with his architecture, and it takes a lot to give up on a fond dream.

So assuming you haven't shown this book the door I guess you'll want to know why this distributed architecture sucks. After all, many tool vendors will tell you that the whole point of distributed objects is that you can take a bunch of objects and position them as you like on processing nodes. Also, their powerful middleware provides transparency. Transparency allows objects to call each other within a process or between a process without having to know if the callee is in the same process, in another process, or on another machine.

Transparency is valuable, but while many things can be made transparent in distributed objects, performance isn't usually one of them. Although our prototypical architect was distributing objects the way he was for performance reasons, in fact his design will usually cripple performance, make the system much harder to build and deploy, or, usually, do both.

Performance Myths

Many organizations have used a "fix-it-later" approach to performance. This approach advocated concentrating on correctness and deferring consideration of performance until the testing phase. Performance problems detected then, were corrected by adding additional hardware, tuning the software (usually in a crisis-mode), or both.

Because it is based on several performance myths, this approach can be dangerous. These myths include:

Performance problems are rare: The reality is that the number, size and complexity of systems has increased dramatically and todays developers are less expert at dealing with performance than their predecessors. As a result, performance problems are all too common.

Hardware is fast and inexpensive: The reality is that processor speeds have increased dramatically, but networks are far slower. Furthermore, software threading issues cause performance problems despite the availability of hardware resources. No one has an unlimited hardware budget, and some software may require more resources than the hardware technology can provide.

Responsive software costs too much to build: This is no longer true thanks to SPE methods and tools. In fact, the "fix-it-later" approach is likely to have higher costs.

You can tune it later: This myth is based on the erroneous assumption that performance problems are due to inefficient coding rather than fundamental architectural or design problems. Re-doing a design late in the process is very expensive.

Exception handling - Patterns, Classification, Best Practices

Exception handling is a programming language construct or computer hardware mechanism designed to handle the occurrence of some condition that changes the normal flow of execution.

Exception safety

A piece of code is said to be exception-safe if run-time failures within the code will not produce ill effects, such as memory leaks, garbled stored data or invalid output. Exception-safe code must satisfy invariants placed on the code even if exceptions occur.

There are several levels of exception safety:
Failure transparency, also known as the no throw guarantee: Operations are guaranteed to succeed and satisfy all requirements even in presence of exceptional situations. If an exception occurs, it will not throw the exception further up. (Best level of exception safety)

Commit or rollback semantics, also known as strong exception safety or no-change guarantee: Operations can fail, but failed operations are guaranteed to have no side effects so all data retain original values.

Basic exception safety: Partial execution of failed operations can cause side effects, but invariants on the state are preserved. Any stored data will contain valid values even if data has different values now from before the exception.

Minimal exception safety also known as no-leak guarantee: Partial execution of failed operations may store invalid data but will not cause a crash, and no resources get leaked.

No exception safety: No guarantees are made. (Worst level of exception safety)

Exception handling Patterns

Here is the list of patterns and questions defining the problems ( For the complete exposition visit here)

Error Object
What characterizes an error? How to structure and administrate error information?

Exception Hierarchy
How to structure error types? What role does inheritance play in the structuring of errors?

Error Traps
What indicators are useful to detect erroneous situations and where to install the traps in the application code?

Assertion Checking Object
How to implement Error Traps in an object oriented language without using a generative approach?

Backtrace
How to collect and trace useful information for the system developers or the maintenance team, so that it supports them by the analysis of the error situation? Especially, if we have no or limited access to the stack administered by the system itself.

Centralized Error Logging
How do you organize exception reporting so that you can offer your maintenance personnel good enough information for analyzing the branch offices problems?

Error Handler
Where and how do you handle errors?

Default Error Handling
How do you ensure that you handle every possible exception correctly (no unhandled exception and limited damage)?

Error Dialog
How to signal errors to an application user?

Resource Preallocation
How to ensure error processing although resources are short?

Checkpoint Restart
How do you avoid a complete rerun of a batch as a result of an error?

Exception Abstraction
How do you generate reasonable error messages without violating abstraction levels?

Exception Wrapper
How do you integrate a ready-to-use library into your exception handling system?

Multithread Exception Handling
How to schedule exceptions in a multithread environment?

Eric Lippert's classification

Writing good error handling code is hard in any language, whether you have exception handling or not. When Eric Lippert first classifies every exception into one of four buckets which he labels fatal, boneheaded, vexing and exogenous. You can read the entire article here.

Fatal exceptions are not your fault, you cannot prevent them, and you cannot sensibly clean up from them.

Boneheaded exceptions are your own darn fault, you could have prevented them and therefore they are bugs in your code. These are all problems that you could have prevented very easily in the first place, so prevent the mess in the first place rather than trying to clean it up.

Vexing exceptions are the result of unfortunate design decisions. Vexing exceptions are thrown in a completely non-exceptional circumstance, and therefore must be caught and handled all the time.

And finally, exogenous exceptions appear to be somewhat like vexing exceptions except that they are not the result of unfortunate design choices. Rather, they are the result of untidy external realities impinging upon your beautiful, crisp program logic.

Best practices

Here is the gist of what Daniel Turini talks in his article Exception Handling Best Practices in .NET.

Plan for the worst

-Check it early
-Don't trust external data
-The only reliable devices are: the video, the mouse and keyboard.
-Writes can fail, too

Code Safely

-Don't throw new Exception()
-Don't put important exception information on the Message field
-Put a single catch (Exception ex) per thread
-Generic Exceptions caught should be published
-Log Exception.ToString(); never log only Exception.Message!
-Don't catch (Exception) more than once per thread
-Don't ever swallow exceptions
-Cleanup code should be put in finally blocks
-Use "using" everywhere
-Don't return special values on error conditions
-Don't use exceptions to indicate absence of a resource
-Don't use exception handling as means of returning information from a method
-Use exceptions for errors that should not be ignored
-Don't clear the stack trace when re-throwing an exception
-Avoid changing exceptions without adding semantic value
-Exceptions should be marked [Serializable]
-When in doubt, don't Assert, throw an Exception
-Each exception class should have at least the three original constructors
-Be careful when using the AppDomain.UnhandledException event

Bulk inserts and updates

A common development task is transferring data between disparate data sources. In this post have outlined a few approaches that can help you to do bulk inserts and updates.

1. Bulk inserts and updates by using the OpenXML method.
OpenXML method is one of the approaches to do bulk inserts and updates with different Microsoft .NET data providers.

Following are two good articles on this
http://support.microsoft.com/kb/315968
http://dotnet.org.za/ncode/archive/2007/05/14/Bulk-Update-and-Insert-of-Object-State-Stored-by-SQL-Server-2000-Using-.NET-C_2300_.aspx

2. SqlBulkCopy to streamline data transfers
The .NET Framework 2.0's SqlBulkCopy class allows you to easily move data programmatically from any data source to a SQL Server table.

Here are some articles that throw light on this
http://video.techrepublic.com.com/5100-10878_11-6187181.html
http://www.codeproject.com/KB/database/TransferUsingSQLBulkCopy.aspx
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlbulkcopy.aspx

3. Bulk copy large files using bcp
The bcp (bulk copy) command allows you to quickly bulk copy large files into SQL Server tables or views. With .NET Framework 1.1, you can utilize bcp via a SqlCommand object.

Following is an article that talks of bcp:

http://www.sqlmag.com/Article/ArticleID/43063/sql_server_43063.html

10 things you should know of Microsoft's SharePoint Services

SharePoint Services is touted as a document management system, and there's a built-in problem with that concept, because we all have a pretty fixed and mundane idea of what a document management system is. SharePoint's Web-centric orientation, however, gives it some unexpected punch, and may change your thinking. Here are some points to consider.

1. SharePoint extends Exchange Server
If you're using Exchange Server to handle your email traffic, SharePoint can greatly simplify distribution.

2. SharePoint collaboration solutions are scalable
Creating sites for team interaction, sharing and management of project-specific documents and files, testing, and other collaborative functions are a natural application of SharePoint. A less hyped aspect of SharePoint is that this collaborative utility is highly scalable.

3. SharePoint sites are highly customizable
SharePoint Services comes fully integrated with FrontPage 2003, so all of FrontPage's WYSIWYG Web editing tools are available for use in crafting SharePoint sites.

4. SharePoint extends InfoPath
InfoPath 2003 is Microsoft's desktop application technology for integrated forms management and data transport. Specifically, you’ll find it useful to publish InfoPath forms directly to a SharePoint library.

5. Metadata can be used to create dynamically parsed storage systems

Metadata is critical to the SharePoint Server concept, and comes in several flavors. With metadata you can effectively create customized search arguments that permit you to organize information dynamically, and to use search criteria from one document library to retrieve information from another.

6. SharePoint can be a data transport mechanism
Depending on what your organization's sites contain, content-wise, and the role(s) the sites are playing in your system, you can actually distribute data from server to server by means of SharePoint's site-moving utilities (see #10).
For instance, if you have SharePoint sites deployed internally to represent data in different workflow stages, the SharePoint content databases of those sites can be rotated in a de facto batch process using these utilities (which are Command Line programs and therefore scriptable).

7. Use the Task Pane to turn Word libraries into collaborative systems with built-in administration
You have a Task Pane that ties documents to libraries, and within it lie a number of important features that take you from the simple management of documents to real collaboration and administration. Through the Task Pane, you can:
track status and versioning of documents
define and track who has site/document access
do task monitoring
create alerts
You can, of course, save from all Office applications—not just Word—to SharePoint.

8. SharePoint can pull data from external databases and other data sources
Data View Web Parts allow you to add views to your sites from a variety of data sources. You can create views specific to your SharePoint sites and link views together. Data sources can be databases, Web services, or any XML source (InfoPath documents, etc.).

9. Leverage Excel for data management
Exporting data to Excel is well-supported in SharePoint and makes graphing and printing convenient (via the Print with Excel and Chart with Excel options). But it's also possible (and may often be desirable) to export data to Excel just for the sake of manageability. The Excel Export function creates an Excel Web query linking to the original data. In this way, you can create spreadsheets that will accept data, and then push that data to SharePoint.

10. Sites and entire site collections can be backed up in a single operation
The ability to move a site, lock-stock-and-barrel (and even more so a site collection, which includes primary site, sub-sites and all their contents), should not be under-appreciated. Anyone who's migrated sites the hard way knows it can be maddeningly frustrating. SharePoint Services includes two utilities that will greatly reduce the frustration: STSADM and SMIGRATE.

SMIGRATE is for backup/restore and for moving sites wholesale. It's a command line utility, so it's tailor-made for scripting, and can simplify the process of moving a site and its contents to the point that it can conceivably be a content distribution tool in some scenarios.

This is a cut down version of the very good article by Scott Robinson and can be read here.

Reporting Services 2008

Reporting Services provides companies with the ability to fill a variety of reporting scenarios.

Managed Reporting

Also often referred to as enterprise reporting - supports the creation of reports that span all aspects of the business and delivers them across the enterprise to provide every employee real time access to information relevant for their business area and enable better decision making.

Ad-Hoc Reporting

Enables users to create their own reports on an ad-hoc basis and provides them with the flexibility to quickly get the information that they need, in the format that they need it without submitting a request and waiting for a report developer to create the report for them.

Embedded Reporting

Enables organizations to embed reports directly into business applications and web portals, enabling users to consume reports within the context of their business process. Deep integration with Microsoft Office SharePoint Server 2007 also enables organizations to deliver reports through a central report library or to use new web parts for thin rendering of reports directly within SharePoint enabling easy creation of dashboards. In this way organizations are able to bring all business critical data, structured as well as unstructured, from across the company together in one central location providing one common experience for information access so that users can see key business performance information at a glance.

Authoring Reports
Report authoring is a major activity in many organizations. Executives, business analysts, managers, and increasingly information workers throughout the enterprise rely on timely and accurate information from easy to understand reports to perform their job effectively. SQL Server 2008 Reporting Services includes comprehensive report authoring tools, and a range of report format innovations that make it easy to create reports that bring data to life and provide the information that employees need in whatever format is most effective for your organization.

Using Report Development Tools

In most organizations, there are two distinct groups of people who create reports; experienced business intelligence solution developers who are used to working in a comprehensive development environment, and business users who are unfamiliar with database schema designs and need an intuitive report design environment that abstracts the underlying technical complexities.

SQL Server 2008 meets both of these needs by providing distinct report development tools specifically designed to meet the needs for these two audiences. This enables developers to create sophisticated reporting solutions for the entire enterprise, while making it easy for business users to focus on the specific data relevant for their business area.

Dundas visualizations platform

With the arrival of SSRS 2008 users will now gain out-of-the-box access to the Dundas visualizations platform. SSRS 2008 (as of the February 2008 CTP build) contains both Dundas Gauge and Dundas Chart products. In addition, according to the prior mentioned Dundas press release it states that Dundas Calendar will also be included into SSRS 2008.

This fairly recent Microsoft purchase of the Dundas source code for integration into SSRS 2008 is a great move as the Dundas suite of SSRS add-ons have become the premier choice for such advanced visualization needs. By including the Dundas technologies into SSRS 2008, Reporting Services customers will not only gain access to a much improved Report Server Architecture (without requiring IIS) but also an enhanced Visualization platform. There are literally about three times as many chart types in SSRS 2008 as compared to SSRS 2005. Some of the brand new chart types include the Funnel, Range, Pyramid, and Polar. In addition to the added chart types customers will also gain access to the Dundas Gauge capabilities via a new Gauge Data Region. Finally, we get a few other ‘goodies’ with the inclusion of Dundas suite including:
Secondary Axes
Runtime Calculated Series
WYSIWYG Chart Editor (design-time)

GRASP Patterns

GRASP stands for General Responsibility Assignment Software Patterns (or sometimes Principles). It is used in object oriented design, and gives guidelines for assigning responsibility to classes and objects...

Larman claims that GRASP can be used as a methodical approach to learning basic object design. These are patterns of assigning responsibilities. He also says that there are two types of responsibilities:

knowing responsibilities that include knowing about private encapsulated data, about related objects, and things it can derive or calculate

doing responsibilities include doing something itself, like creating another object or doing a calculation, initiating action in other objects, and controlling and coordinating activities in other objects.

The full set of GRASP patterns are:
Information Expert
Creator
Controller
Low Coupling
High Cohesion
Polymorphism
Pure Fabrication
Indirection
Protected Variations

Information Expert

The Information Expert pattern provides the general principles associated with the assignment of responsibilities to objects. The information expert pattern states that responsibility should be assigned to the information expert—the class that has all the essential information. Systems which appropriately utilize the information expert pattern are easier to understand, maintain and expand as well as increase the possibility that an element can be reused in future development.

Related patterns are
Low Coupling/High Cohesion : The Expert pattern promotes low coupling by putting methods in the classes that have the information that the methods need. Classes whose methods only need the class’ own information have less need to rely on other classes. A set of methods that all operate on the same information tends to be cohesive.

Creator

The Creator pattern solves the problem of who should be responsible for the creation of a new instance of a class. The creator pattern is important because creation of objects is one of the most ubiquitous activities in an object-oriented system. A system that effectively utilizes the creator pattern can also support low coupling, increased understandability, encapsulation and the likelihood that the object in question will be capable of sustaining reuse. Given two classes, class B and Class A, class B should be responsible for the creation of A if class B contains or compositely aggregates, records, closely uses or contains the initializing information for class A. It could then be stated that B is natural object to be a creator of A objects.

The Factory pattern is a common alternative to Creator when there are special considerations, such as complex creation logic. This is achieved by creating a Pure Fabrication object (see below), called Factory that handles the creation.

Controller

The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers). It is defined as the first object beyond the UI layer that receives and coordinates ("controls") a system operation. The controller should delegate to other objects the work that needs to be done; it coordinates or controls the activity. It should not do much work itself. The GRASP Controller can be thought of as being a part of the Application/Service layer (assuming that the application has made an explicit distinction between the App/Service layer and the Domain layer) in an object-oriented system with common layers.

Related patterns are
Pure Fabrication: The Controller pattern is a specialized form of the Pure Fabrication pattern.
Mediator: The Mediator pattern is used to coordinates events from a GUI. Like controller objects, a highly coupled and incohesive mediator object may involve less overall complexity than an arrangement that distributes the same responsibilities over more objects.

Low Coupling

Low Coupling is an evaluative pattern, which dictates how to assign responsibilities to support:
low dependency between classes;
low impact in a class of changes in other classes;
high reuse potential;

Related patterns are
Interface: One form of coupling between classes is the coupling between a subclass and its superclass. It is often possible to avoid subclassing by using the Interface pattern.
Mediator: It is not necessary or even always desirable for all of the classes in a design to have low coupling and high cohesion. Sometimes the overall complexity of a class can be reduced by concentrating complexity in one class. The Mediator pattern provides an example of that.
Composed Method: It is possible for methods to be uncohesive and difficult to work with. Some common causes are excessive length or too many execution paths within a method. The Composed Method pattern provides guidance of breaking up such methods into smaller, simpler and more cohesive methods.

High Cohesion

High Cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable and understandable. High cohesion is generally used in support of Low Coupling. High cohesion means that the responsibilities of a given element are strongly related and highly focused. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system. Alternatively, low cohesion is a situation in which a given element has too many unrelated responsibilities. Elements with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to maintain and adverse to change.

Related patterns same as related patterns for Low Coupling

Polymorphism

According to the Polymorphism pattern, responsibility of defining the variation of behaviors based on type is assigned to the types for which this variation happens. This is achieved using polymorphic operations.

Related patterns are
Dynamic Linkage You can implement plug-ins or pluggable software components using a combination of polymorphism and the Dynamic Linkage pattern.

Pure Fabrication

A pure fabrication is a class that does not represent a concept in the problem domain, specially made up to achieve low coupling, high cohesion, and the reuse potential thereof derived (when a solution presented by the Information Expert pattern does not). This kind of class is called "Service" in Domain-driven design.

Related patterns are
Low Coupling/High Cohesion The point of the Pure Fabrication pattern is to maintain the low coupling and high cohesion of the classes in an object oriented design.

Indirection

The Indirection pattern supports low coupling (and reuse potential) between two elements by assigning the responsibility of mediation between them to an intermediate object. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern.

Related patterns are
Low Coupling/High Cohesion: The fundamental motivation for the Don’t Talk to Strangers pattern is to maintain low coupling.
Pure Fabrication: There are sometimes good reasons for calls made to classes added to a design using the Pure Fabrication pattern to violate the guidelines of the Don’t Talk to Strangers pattern.
Mediator: The Mediator pattern provides an example of a class created through pure fabrication that receives direct method calls from classes unrelated to it with a benefit that outweighs the disadvantages of the direct calls.

Protected Variations
The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

"The critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology" (Larman, Craig. Applying UML and Patterns - Third Edition). Thus, GRASP is really a mental toolset, a learning aid to help in the design of object oriented software.

Gang of Four (GoF) patterns

The Gang of Four (GoF) patterns are generally considered the harbinger of the whole software patterns movement. They are categorized in three groups: Creational, Structural, and Behavioral.

· Creational patterns create objects for you rather than having you instantiate objects directly. This gives your program more flexibility indeciding which objects need to be created for a given case.

· Structural patterns help you compose groups of objects into larger structures, such as complex user interfaces or accounting data.

· Behavioral patterns help you define the communication between objects in your system and how the flow is controlled in a complex program.

Creational patterns

Abstract factory
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
Factory method
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
Builder
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
Prototype
Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
Singleton
Ensure a class only has one instance, and provide a global point of access to it.

Structural patterns

Adapter
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
Bridge
Decouple an abstraction from its implementation so that the two can vary independently.
Composite
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
Decorator
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
Facade
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
Flyweight
Use sharing to support large numbers of fine-grained objects efficiently.
Proxy
Provide a surrogate or placeholder for another object to control access to it.

Behavioral patterns

Chain of responsibility
Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
Command
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
Interpreter
Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.
Iterator
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
Mediator
Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
Memento
Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.
Observer
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
State
Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
Strategy
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Template method
Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.
Visitor
Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Design patterns

The origin of design patterns lies in work done by an architect named Christopher Alexander during the late 1970s. He began by writing two books, A Pattern Language and A Timeless Way of Building which, in addition to giving examples, described his rationalle for documenting patterns. The pattern movement became very quiet until 1987 when patterns appeared again at an OOPSLA conference.

Design patterns gained popularity in computer science after the book Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994 (Gamma et al.). The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups: Creational, Structural, and Behavioral.

What are Design Patterns?

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.

Why Study Design Patterns?

Now that we have an idea about what design patterns are, let us see, "Why to study them?" There are several reasons that are obvious and some that are not so obvious.

The most commonly stated reasons for studying patterns are because patterns allow us to:

Reuse solutions— By reusing already established designs, we get a head start on our problems and avoid gotchas. We get the benefit of learning from the experience of others. We do not have to reinvent solutions for commonly recurring problems.

Establish common terminology— Communication and teamwork require a common base of vocabulary and a common viewpoint of the problem. Design patterns provide a common point of reference during the analysis and design phase of a project.

However, there is a third reason to study design patterns:

Patterns give a higher-level perspective on the problem and on the process of design and object orientation. This frees from the tyranny of dealing with the details too early.

Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

Notable books in the design pattern genre include:

Fowler, Martin (2002). Patterns of Enterprise Application Architecture. Addison-Wesley. ISBN 978-0321127426.

Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 0-201-63361-2.

Hohpe, Gregor; Bobby Woolf (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. ISBN 0-321-20068-3.

Reporting Solution Alternatives

The following section discusses some common reporting solution alternatives. The alternatives usually represent an evolution in a company’s reporting sophistication. Generally, organizations start with some main reports from an OLTP (Online Transaction Processing) system. Once they meet the limitations of the OLTP system, they evolve their reporting into data warehouses. Eventually, even more complex reports and interactivity are required. This usually leads to the implementation of an OLAP system. We will take a look at each of these alternatives and their relative advantages.

Reporting with Relational Data (OLTP)

Transactional databases are designed to capture and manage real data as it is generated, for example, as products are purchased and as services are rendered. Relational databases are designed according to the rules of normal form and typically have many tables, each containing fragments of data rather than comprehensive information or business facts. This helps preserve the integrity and accuracy of data at the detail level, but it presents challenges for deriving useful information from a large volume of transactional data. In order to obtain information with meaningful context, tables must be joined and values must be aggregated.

For simple report requests, this usually is not an issue. Take the example of an invoice. An invoice is a simple report. It displays custom information along with detail for a small number of transactions. For this type of report, querying an OLTP system is not very costly and the query should be relatively straightforward. However, users will eventually move past these simple reports as they start to look for information for an entire year or product line. Developing these types of reports will eventually consume considerable resources on an OLTP system as well as require increasingly difficult queries. Although relational database systems may support complex queries, reporting against these queries routinely could prove to be slow and inefficient.

Relational Data Warehouses

Many organizations evolve away from reporting on their OLTP data. Usually their first step is to create a carbon copy of the OLTP system on another server. This alleviates the resource constraints on the original system, but it does not solve the issues around increasingly difficult queries. OLTP systems simply are not organized in a logical reporting structure.

To deal with increasing reporting needs, an entire industry has evolved to simply handle reporting. From this industry, individuals such as Ralph Kimball have refined standard patterns and methodologies for developing data warehouses. A common misconception is that a data warehouse is simply a denormalized transactional system. In reality, a data warehouse is another form of relational database that is organized into a reporting-friendly schema. Data is centered around what is known as a “fact” table. A fact table relates to business processes such as orders or enrollments. Radiating out from the fact table are dimensional tables. Dimensional tables contain attributes that further define the facts. These attributes could contain product names, geographic sales locations, or time and date information.

Relational data warehouses can significantly improve query performance on large data sets. However, they too have related drawbacks. These drawbacks generally relate to the fact that data is still stored in a relational format. Relational databases require joins to combine information. They also require aggregate functions to calculate summary-level detail. Both joins and aggregate functions can slow queries on very large sets of data. Relational databases also do not understand inherit associations in the data. Take the example of a product table. Each product table has a related subcategory and each subcategory has a related category. If you need to create a report that is product sales with its percentage makeup of each related subcategory, you have to understand the relationship and write it in your query. The same holds true for time relationships. If you need to create a report that contains year-to-date information, you need to understand what the current date is as well as all the related periods in the same year. These things are possible in SQL queries but take additional effort and require more maintenance. That moves us into our next type of reporting alternative: OLAP.

Reporting with Multidimensional Data (OLAP)

Multidimensional databases take a much different approach to data retrieval and storage than relational databases. Multidimensional databases are organized into objects called cubes. Cubes act as a semantic layer above your underlying database. These databases can contain numerous different relationships and very large sets of aggregate data.

As a multidimensional database, information can be aggregated across many dimensions. This data is preprocessed into the multidimensional structure. Because it is preprocessed, query times are significantly reduced for large additive data sets. Multidimensional databases also have the advantage of understanding relationships between and across dimensions. This opens the door to creating calculations and reports that would be extremely difficult in a relational database.

Imagine that a user asks you to create a report that displays the top five customers with their top three products by this year’s sales amount and compared to last year’s sales amount. Writing a SQL query to return the top five customers is fairly straightforward. However, returning each one’s top three products would require additional subqueries because the relational database does not understand the association between products and customers. The final part of the request can prove even more burdensome. Returning a single year’s data is easy, but nesting that data next to last year’s data can prove almost impossible. The SQL query for the above scenario would most likely contain a number of nested queries as well as some creative use of temporary tables. Besides being a terribly complex query, it probably would not perform that well. On the other hand, Multidimensional Expressions (MDX), the language used to query multidimensional databases, can handle this in a few simple calls—not because MDX is a more advanced language, but simply because the underlying database understands the associations in the data and has stored this information for quick retrieval.

References: Professional SQL Server™ 2005 Reporting Services

Domain-Driven Design

The most complicated aspect of large software projects is not the implementation, it is the real world domain that the software serves. Over the last decade or two, a Domain-Driven Design philosophy has developed as an undercurrent in the object community.

What Is Domain-Driven Design?

Domain-driven design (DDD) is an approach to the design of software, based on the two premises that complex domain designs should be based on a model, and that, for most software projects, the primary focus should be on the domain and domain logic (as opposed to being the particular technology used to implement the system). The term was coined by Eric Evans in his book of the same title.

Domain-driven design is not a technology or a methodology. It is a vision and approach for dealing with highly complex domains that is based on making the domain itself the main focus of the project, and maintaining a software model that reflects a deep understanding of the domain. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, teams need an extensive set of design practices, techniques and principles.

In DDD a number of specific software design patterns are useful, such as:

Entities (a.k.a. Reference Objects): An object in the domain model that is not defined by its attributes, but rather by a thread of continuity and identity.

Value Objects: An object that has no conceptual identity. These objects describe a characteristic of a thing.

Repository: methods for retrieving domain objects should delegate to a specialised 'repository' object such that alternative implementations may be easily interchanged.

Factory: methods for creating domain objects should delegate to a specialised 'factory' object such that alternative implementations may be easily interchanged.

Service: When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services. The Service concept is called "Pure Fabrication" in GRASP.

Some of the very good books for reference are :

Domain-Driven Design: Tackling Complexity in the Heart of Software

In the book Domain-Driven Design a number of high-level concepts and practices are articulated, such as ubiquitous language meaning that the domain model should form a common language for describing system requirements, that works equally well for the business users or sponsors and for the software developers. The book is very focused at describing the Domain layer which is one of the common layers in an object-oriented system with a multilayered architecture.

With this book in hand, object-oriented developers, system analysts, and designers will have the guidance they need to organize and focus their work, create rich and useful domain models, and leverage those models into quality, long-lasting software implementations.

Applying Domain-Driven Design and Patterns: With Examples in C# and .NET

From the Back Cover
“[This] is a book about design in the .NET world, driven in an agile manner and infused with the products of the enterprise patterns community. [It] shows you how to begin applying such things as TDD, object relational mapping, and DDD to .NET projects...techniques that many developers think are the key to future software development.... As the technology gets more capable and sophisticated, it becomes more important to understand how to use it well. This book is a valuable step toward advancing that understanding.”
– Martin Fowler, author of Refactoring and Patterns of Enterprise Application Architecture

Patterns, Domain-Driven Design (DDD), and Test-Driven Development (TDD) enable architects and developers to create systems that are powerful, robust, and maintainable.

Drawing on seminal work by Martin Fowler (Patterns of Enterprise Application Architecture) and Eric Evans (Domain-Driven Design), Jimmy Nilsson shows how to create real-world architectures for any .NET application. Nilsson illuminates each principle with clear, well-annotated code examples based on C# 1.1 and 2.0. His examples and discussions will be valuable both to C# developers and those working with other .NET languages and any databases–even with other platforms, such as J2EE.

WPF Globalization and Localization

When you limit your product's availability to only one language, you limit your potential customer base to a fraction of our world’s 6.5 billion population. If you want your applications to reach a global audience, cost-effective localization of your product is one of the best and most economical ways to reach more customers.

Globalization is the design and development of applications that perform in multiple locations. For example, globalization supports localized user interfaces and regional data for users in different cultures. WPF provides globalized design features, including automatic layout, satellite assemblies, and localized attributes and commenting.

Localization is the translation of application resources into localized versions for the specific cultures that the application supports.

There are different approaches to implement Globalization and Localization in WPF. Here are the list of few (Refer to the XAML localization blog by Robert)

Localization via use of resx files and custom code generator for public resource class (this generator is used due to wpf binding engine restriction - you can bind data only from public properties/fields in public classes) : pros - supports design-time; easy to use (just create ObjectDataProvider, put your resources' class in it and bind your strings to DEPENDENCY properties of objects in xaml). Cons result from pros (pardon me my English) - first of all we are strongly restricted in use, 'cause binding can be applied ONLY to the dependency properties of the DependencyObject descendants; and second disadvantage is that additional VS installation (custom resource generator tool) is required.

Localization via LocBaml (simplified variant - it uses ResourceDictionary with localizable strings that are used by merging this dictionary in Application.Resources.MergedDictionaries and referring to them by means of DynamicResource extension) it is still not straightforward enough, because Locbaml forces us to compile binaries twice.

Localization via LocBaml (official MS tutorial)
Main difference here is that article author writes wrappers of resources classes manually. But I've got almost 50 projects in my solution. I don't want to write this bunch of classes manually. (Suddenly I thought that Paul Stovell's idea with custom type descriptors could be useful here... or wrapping could become less complicated via file reference in VS... I'll think about it later... Main advantage of described solution is the ability to switch languages in runtime.

Localization via xml files, XmlDataProvider, XPath queries in Binding : This is thee most elegant solution among all listed here. Pros - design-time support and runtime language switching. The only disadvantage is complexity of files' maintenance.

Other good references:

http://msdn.microsoft.com/en-us/library/ms788718.aspx

http://www.odewit.net/ArticleContent.aspx?id=WpfLocalization&format=html&lang=en

Claims-based Security

Traditional security models for intranet and Internet applications use some form of username and password to authenticate users. Client-server applications deployed to a common domain often rely on Windows credentials (NTLM or Kerberos), while services exposed to the Internet often require a username and password to be passed in an interoperable format (WS-Security) to be authenticated against a custom credential store. These scenarios are frequently accompanied by role-based security checks that authorize access to functionality. Although popular, role-based security is often too coarse an approach since custom roles are often necessary to represent different combinations of permissions or rights. Thus, applications are usually better off authorizing calls based on permissions granted, using roles to gather the appropriate permission set. This type of permission-based security model will provide a more fine-grained result over role-based security – the downside is that .NET doesn’t inherently support it so it requires more work to implement.

WCF introduces a claims-based approach to security at service boundaries, improving on role-based and permission-based security models. Claims can represent many different types of information including identity, roles, permissions or rights and even general information about the caller that may be useful to the application. A set of claims is also vouched for by an issuer such as a security token service, adding credibility to the information described by each claim – something not present in role-based or permission-based models. An additional benefit of using a claims-based security model is that it supports federated and single sign-on scenarios.

Michele Leroux Bustamante has written a very good article on Claims-based Security Model (Part 1 Part 2 ). This two-part article will explain how claims-based security is supported by WCF, and show you how to implement a claims-based security model for your services.

Microsoft Code Name “Zermatt”

The Federated Identity team has offered a public beta of Microsoft Code Name "Zermatt". Zermatt is a framework for implementing claims-based identity in your applications. By using it, you’ll more easily reap the benefits of the claims-based identity model described in this paper. For more information, see Zermatt White Paper for Developers.

Remote Debugging

Today we faced an interesting challenge. We had a service runioing remotely and we needed to debug it. Though we selected the easiest option, that is, we checked if VS2008 was on QA machine and debugged locally. My search for remote debugging led me to some very interesting articles.

http://andrasvass.blogspot.com/2008/05/howto-visual-studio-remote-debugging.html

This howto focuses mainly on setting up and configuring Visual Studio 2008 (should work with Visual Studio 2005 as well) remote debugging where the client machine that runs the IDE is not on a domain or is not on the same domain as the target machine. You may as well find this howto useful if you connect via a virtual private network and want to develop or debug your server applications from there or you have problems connecting to the remote debugger service.

http://support.microsoft.com/kb/318041
This step-by-step article describes how to set up and use remote debugging in Microsoft Visual Studio .NET or in Microsoft Visual Studio 2005.

http://support.microsoft.com/kb/910448

Remote debugging is considered one of the toughest topics in ASP.NET, but it's a really cool feature and is really helpful when we cannot have a local Web server or when we have to store the applications at a centralized location. This column covers how to set up and use remote debugging in Visual Studio 2005.

Exception handling in Sql Server

Exception handling is a programming language construct or computer hardware mechanism designed to handle the occurrence of some condition that changes the normal flow of execution.

Error handling plays a vital role when writing stored procedures or scripts. Sql server has matured with years and here is how the error handling is being address

SQL Server Versions before 2005

SQL Server versions before 2005 offered only one simple way to work with exceptions: the @@ERROR function. This function can be used to determine if an error occurred in the last statement that was executed before evaluating @@ERROR.

For example:

SELECT 1/0

SELECT @@ERROR
-----------

Msg 8134, Level 16, State 1, Line 1

Divide by zero error encountered.
-----------
(1 row(s) affected)

In this case @@ERROR returns 8134, which is the error number for a divide-by-zero error.
Using @@ERROR, you can detect errors and control them to some degree. However, proper use of this function requires that you check it after every statement; otherwise it will reset, as shown in the following example:

SELECT 1/0

IF @@ERROR <> 0

BEGIN

SELECT @@ERROR

END
-----------

Msg 8134, Level 16, State 1, Line 1

Divide by zero error encountered.
-----------0

(1 row(s) affected)

Trying to catch the error in this case actually ends up resetting it; the @@ERROR in the SELECT returns 0 rather than 8134 because the IF statement did not throw an exception.

In addition to the fact that the exception resets after each statement, @@ERROR does not actually handle the exception -- it only reports it. The exception is still sent back to the caller, meaning that even if you do something to fix the exception in your T-SQL code, the application layer will still receive a report that it occurred. This can mean additional complexity when creating application code because you need to handle exceptions that may needlessly bubble up from stored procedures.

SQL Server 2005

In SQL Server 2005, exceptions can now be handled with a new T-SQL feature: TRY/CATCH blocks. This feature emulates the exception handling paradigm that exists in many languages derived from the C family, including C/C++, C#, Java and JavaScript. Code that may throw an exception is put into a try block. Should an exception occur anywhere in the code within the try block, code execution will immediately switch to the catch block, where the exception can be handled.

The term "catch" is of special importance here. When TRY/CATCH is used, the exception is not returned to the client. It is "caught" within the scope of the T-SQL that caused it to be thrown.
For an example of TRY/CATCH, consider a divide-by-zero error:

BEGIN TRY

SELECT 1/0

END TRY

BEGIN CATCH

SELECT 'Error Caught'

END CATCH
-----------
(0 row(s) affected)
------------

Error Caught
(1 row(s) affected)

When this batch is run, no exception is reported. Instead, the message "Error Caught" is selected back. Of course, your T-SQL code does not have to send back any kind of specific message in the CATCH block. Any valid T-SQL can be used, so you can log the exception or take action to remedy the situation programmatically, all without reporting it back to the caller.

While merely being able to catch an exception is a great enhancement, T-SQL is also enhanced with new informational functions that can be used within the CATCH block. These functions are: ERROR_MESSAGE(), ERROR_NUMBER(), ERROR_LINE(), ERROR_SEVERITY(), ERROR_STATE() and ERROR_PROCEDURE(). Unlike @@ERROR, the values returned by these functions will not reset after each statement and, as a result, the functions will return consistent values over the entire time a CATCH block is executed.

For instance:
BEGIN TRY

SELECT 1/0

END TRY

BEGIN CATCH

SELECT 'Error Caught'

SELECT ERROR_MESSAGE(), ERROR_NUMBER()

END CATCH
-----------
(0 row(s) affected)
------------Error Caught
(1 row(s) affected)
-------------------------------------------- ---------------

Divide by zero error encountered. 8134
(1 row(s) affected)
In this example, the ERROR_MESSAGE() and ERROR_NUMBER() functions return the correct values, even though a SELECT occurred between the exception and evaluation of the functions -- quite an improvement over @@ERROR!

References

Exception handling best practices in SQL Server 2005

http://searchsqlserver.techtarget.com/tip/1,289483,sid87_gci1189087,00.html

Coding and Design Guidelines

A coding standard is a set of guidelines, rules and regulations on how to write code. Usually a coding standard includes guide lines on how to name variables, how to indent the code, how to place parenthesis and keywords etc. The idea is to be consistent in programming so that, in case of multiple people working on the same code, it becomes easier for one to understand what others have done. Even for individual programmers, and especially for beginners, it becomes very important to adhere to a standard when writing the code. The idea is, when we look at our own code after some time, if we have followed a coding standard, it takes less time to understand or remember what we meant when we wrote some piece of code.

C# Coding Guidelines

Here are a number of article that can serve as good reference.

http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=336
http://blogs.msdn.com/ericgu/archive/2004/01/19/60315.aspx
http://www.tiobe.com/standards/gemrcsharpcs.pdf

Design Guidelines for Class Library Developers

The .NET Framework's managed environment allows developers to improve their programming model to support a wide range of functionality. The goal of the .NET Framework design guidelines is to encourage consistency and predictability in public APIs while enabling Web and cross-language integration. It is strongly recommended that you follow these design guidelines when developing classes and components that extend the .NET Framework. Inconsistent design adversely affects developer productivity. Development tools and add-ins can turn some of these guidelines into de facto prescriptive rules, and reduce the value of nonconforming components. Nonconforming components will function, but not to their full potential.

These guidelines are intended to help class library designers understand the trade-offs between different solutions. There might be situations where good library design requires that you violate these design guidelines. Such cases should be rare, and it is important that you provide a solid justification for your decision. The section provides naming and usage guidelines for types in the .NET Framework as well as guidelines for implementing common design patterns.

Refer MSDN for design guidelines above at http://msdn.microsoft.com/en-us/library/czefa0ke.aspx

Source Code Comments

In computer programming, a comment is a programming language construct used to embed information in the source code of a computer program.

According to Jeffrey Kotula,"Source code documentation is a fundamental engineering practice critical to efficient software development. Regardless of the intent of its author, all source code is eventually reused, either directly, or just through the basic need to understand it. In either case, the source code documentation acts as a specification of behavior for other engineers. Without documentation, they are forced to get the information they need by making dangerous assumptions, scrutinizing the implementation, or interrogating the author. These alternatives are unacceptable. Although some developers believe that source code "self-documents", there is a great deal of information about code behavior that simply cannot be expressed in source code, but requires the power and flexibility of natural language to state. Consequently, source code documentation is an irreplaceable necessity, as well as an important discipline to increase development efficiency and quality."(For more quotes click here).

C# offers several XML tags that can be placed directly within your source files to document the code, and Microsoft documents these tags very nicely in Visual Studio .NET help files. Once the developer has documented her source using the XML tags, she can use Sandcastle to produce integrated .chm files that contain the source documentation.

Although the description above and in the article may use the term ‘comment’, the XML tags are used to produce external source documentation. This differs from traditional code comments in that the realized documentation can be distributed as API (Application Programmer’s Interface) documentation. (For more details refer here.)

The following information outlines what you need to install so you can create proper Inline API (MSDN-style) documentation. Here is a list of programs you need to install.

Sandcastle

Sandcastle produces accurate, MSDN style, comprehensive documentation by reflecting over the source assemblies and optionally integrating XML Documentation Comments. Sandcastle has the following key features

* Works with or without authored comments* Supports Generics and .NET Framework 1.1, 2.0, 3.0, 3.5 and other released versions of Framework* Sandcastle has 2 main components (MrefBuilder and Build Assembler)* MrefBuilder generates reflection xml file for Build Assembler* Build Assembler includes syntax generation, transformation, etc* Sandcastle is used to build Microsoft Visual Studio and .Net Framework documentation.

You can download it from CodePlex http://www.codeplex.com/Sandcastle

SHFB (Sandcastle Help File Builder)

SHFB is a GUI interface that almost looks identical to the NDoc interface so anyone familiar with NDoc should be quite comfortable using it. It uses the underlining Sandcastle API to generate an HTML 1.x (.CHM) file, an HTML 2.x (.HxS) file, and/or a web site.

You can download SHFB from CodePlex http://www.codeplex.com/SHFB

DocProject for 2008

DocProject drives the Sandcastle help generation tools using the power of Visual Studio 2005/2008 and MSBuild. Choose from various project templates that build compiled help version 1.x or 2.x for all project references. DocProject facilitates the administration and development of project documentation with Sandcastle, allowing you to use the integrated tools of Visual Studio to customize Sandcastle's output.

You can download DocProject from CodePlex http://www.codeplex.com/DocProject