Microsoft .Net Framework 3.0

Vice President S. Somasegar describes the decision to rename WinFX to the .NET Framework 3.0. Now the WinFX technology you know has a name that identifies it for exactly what it is—the next version of the Microsoft developer framework

for more information please follow this link.

VSTS Database Professional

New Version of Visual Studio Team System is alive now...

Visual Studio Team Edition for Database Professionals.

You can find out more about it and get access to early community technology previews here.

Provider Pattern (Overview)

Provider Pattern

A provider is simply a contract between an API and the Business Logic/Data Abstraction Layer. A provider implementation must derive from an abstract base class, which is used to define a contract for a particular feature

Common Behaviors/Characteristics:
Below is a listing of characteristics common to providers.

1. Base class
A base class should have as few methods and properties as possible. This is desirable to encourage developers to write providers.

2. Threading
Providers should be free-threaded/thread safe, with one instance per application domain. Any provider-specific objects created more frequently (for example, one per request) should be created through provider APIs.

3. Factory methods
The abstract base class should support factory methods to create new objects wherever appropriate.

If a feature allows a provider to create a framework object, but does not allow the provider to extend the object, the framework class should be sealed.

Complex objects created by a provider may keep track of the provider that created it, and expose it as a Provider property. This allows users of the feature to determine the provider that owns the data for the object. For example, when a new user is created with the Membership API, it may be useful for the developer to be aware of the provider that data for the object is stored in.

4. Class naming and namespaces
The specific provider base classes should be named [Feature]ProviderBase.

5. Common naming patterns for provider classes
Figure 5 below calls out some of the common names and casing that should be used for various data stores (where name is [Name][Feature]Provider).




Refrence: Provider Model Design Pattern and Specification, Part 1

Sample Code HERE

Good Luck & happy programming.

Master-Slave Replication Pattern

Data Patterns (Master-Slave Replication Pattern)

As we know there is a punch of data patterns and today we are going to discuss one of them (Master-Slave Replication Pattern).

Why do I need Master-Slave Replication Pattern?
You may need Master-Slave replication pattern if you have to synchronize data from the source to the target without transmitting back the data to the source (One-way synchronizing). This means the data will be copied to the target without regard to any updates occurred on the target since the last replication.

The following figure shows the Master-Slave Replication.


Acquire
Reads the content of the Replication Set (Data) from the source to get the ONLY the updated data.

Manipulate
Manipulating & preparing the Replication Set (Data) to be copy to the target. Usually this manipulation includes data type converting, concatenating and splitting fields (e.g. Extracting first name from a full name).

Write
Writing the manipulated data (from the previous step) to the target. This operation either overwrites the data on the target, or compares the data with the manipulated data and copy the updated data only.


Reference:
Microsoft Data Patterns