Transaction-,SQL Transaction

What Is Transaction And Type Of Transaction In SQL

A transaction in SQL is a larger unit of database processing that contains one or more database access operations like insertion ,deletion, retrieval and modification operations.

These transaction are required to fulfil certain characteristics and they are :

ACID Property

Atomicity: The transaction is either performed entirely or not performed at all.

Isolation: The transaction should not be interfered by any other transaction executing concurrently.
Durability: The changes made by the transaction should be permanently committed in the database.
Consistency : If the database was consistent before the execution of the transaction .It should remain consistent after the complete execution of that transaction.

There are two types of transactions: explicit and implicit

Explicit are those that need to be specified like : commit and roll-back

Commit transaction signals that the transaction was successfully executed and the changes/ updates (if any) made by the transaction have been committed to the database and these changes cannot be undone.

Roll-back signals that the transaction was not successfully executed , and the changes/updates made by the transaction have to be undone.

Implicit transactions are those that mark beginning and end of the transaction, each statement like update, delete , insert run within these implicit transactions.,However, you can explicitly specify the beginning and ending of the transaction by "begin transaction" and "end transaction" statements respectively. All the statements within these two boundaries will be marked as one transaction.

Design Patterns-Singleton Pattern

Singleton Pattern

The intent of the Singleton pattern defined in Design Patterns is -
To "ensure a class has only one instance, and provide a global point of access to it".

what problem does this solve,?
what is our motivation to use it?

In nearly every application, there is a need to have an area from which to globally access and maintain some type of data. There are also cases in object-oriented (OO) systems where there should be only one class, or a predefined number of instances of a class, running at any given time. For example, when a class is being used to maintain an incremental counter, the simple counter class needs to keep track of an integer value that is being used in multiple areas of an application. The class needs to be able to increment this counter as well as return the current value. For this situation, the desired class behavior would be to have exactly one instance of a class that maintains the integer and nothing more.

Another simple example is :
You are creating Database connection class.creating its object and sharing in the project.

Logical Model

The model for a singleton is very straightforward. There is (usually) only one singleton instance. Clients access the singleton instance through one well-known access point. The client in this case is an object that needs access to a sole instance of a singleton.

Sample Singleton Usage

sealed class SingletonCounter {
public static readonly SingletonCounter Instance =
     new SingletonCounter();
private long Count = 0;
private SingletonCounter() {}
public long NextValue() {
    return ++Count;
}
}

class SingletonClient {
[STAThread]
static void Main() {
    for (int i=0; i<20;>
----------------------------------------
The Singleton design pattern is a very useful mechanism for providing a
single point of object access in an object-oriented application.
Regardless of the implementation used, the pattern provides a commonly
understood concept that can be easily shared among design and
development teams.


The .NET Framework goes a long way to help an implementer
of a pattern design the type of functionality desired without having to
deal with many of the side effects discussed in this article.

Difference between MVC and MVP patterns

Difference between MVC and MVP patterns:
In the MVP the UI frontend only interacts with the View and not with the controller. The View is therefore more than just an observer. What this means is that when a user action is received by the page in case of the MVC this is sent to the controller. In case of MVP the user action is sent by the UI page to the view which then in turn calls the presenter. See my diagram below:

Advantages of MVP over MVC

The distinct advantage that MVP has over MVC is that MVP is a better bet for UI intensive projects. MVP is also more accommodating towards mock tests. Some disadvantages of MVP include the time taken to re-factor code to fit this pattern. MVC is better suited for projects with complex navigation. MVP is more suited for winform projects than MVC. Also where applications need to support both winforms and webforms then MVP is the best bet. Because in such cases the Model and the Presenter code can be reused as is.

The MVP is now considered “retired” and is only referred to by its two variants. One a “MVP - Supervising controller” and two a “MVP - Passive View”. The distinction is based on the degree of control a presenter exercises over a view. Advantages in using a Passive View is that it is more testable via mocks. But a supervising controller is more suited than a passive model for heavy UI data that includes grids or lists. Disadvantages of both these types: inclusion of extra levels of layers of code, and a possible lack of awareness of the presenter of changes to the model.


Advantages of MVC over MVP

So where does MVC score over the MVP? MVC takes lesser development time than an MVP. This also takes lesser testing effort than the MVP and suffices for most small medium projects. Also the key to any good design is good controller. So for most projects MVC would suffice.

source: consultingblogs.emc.com