http://www.codeplex.com/aspnet/Release/ProjectReleases.aspx?ReleaseId=14924

Hayırlara vesile olsun...

sp_executesql has the same behavior as EXECUTE with regard to batches, the scope of names, and database context. The Transact-SQL statement or batch in the sp_executesql stmt parameter is not compiled until the sp_executesql statement is executed. The contents of stmt are then compiled and executed as an execution plan separate from the execution plan of the batch that called sp_executesql. The sp_executesql batch cannot reference variables declared in the batch that calls sp_executesql. Local cursors or variables in the sp_executesql batch are not visible to the batch that calls sp_executesql. Changes in database context last only to the end of the sp_executesql statement.

sp_executesql can be used instead of stored procedures to execute a Transact-SQL statement many times when the change in parameter values to the statement is the only variation. Because the Transact-SQL statement itself remains constant and only the parameter values change, the SQL Server query optimizer is likely to reuse the execution plan it generates for the first execution.

Ex:

USE AdventureWorks;
GO
DECLARE @SQLString nvarchar(500);
DECLARE @ParmDefinition nvarchar(500);
DECLARE @SalesOrderNumber nvarchar(25);
DECLARE @IntVariable int;
SET @SQLString = N'SELECT @SalesOrderOUT = MAX(SalesOrderNumber)
  FROM Sales.SalesOrderHeader
  WHERE CustomerID = @CustomerID';
SET @ParmDefinition = N'@CustomerID int,
                       @SalesOrderOUT nvarchar(25) OUTPUT';
SET @IntVariable = 22276;
EXECUTE sp_executesql
  @SQLString,
  @ParmDefinition,
  @CustomerID = @IntVariable,
  @SalesOrderOUT = @SalesOrderNumber OUTPUT;
-- This SELECT statement returns the value of the OUTPUT parameter.
SELECT @SalesOrderNumber;
-- This SELECT statement uses the value of the OUTPUT parameter in
-- the WHERE clause.
SELECT OrderDate, TotalDue
FROM Sales.SalesOrderHeader
WHERE SalesOrderNumber = @SalesOrderNumber;

References: http://technet.microsoft.com/en-us/library/ms188001.aspx

Google Product Search eticaret'in rengini değiştirecek gibi,

bir ürünün aramasını yapıyorsun onunla ilgili tüm ürünler farklı markalar veya farklı tedarikciler fiyatları ile geliyor.

Bu serbest ekonominin tam dijitaleşmesi olsa gerek :)

İşte Rekabet :)

http://www.google.com/products

incelemenizi tavsiye ederim.

public class DALProduct

static DALProduct()

//singleton cache nesnesi

if (_ProductCache==null)

_ProductCache = new Dictionary<int, Product>();

private static Dictionary<int, Product> _ProductCache;

public static Product GetbyProductID(int ID)

if (_ProductCache.ContainsKey(ID))

else

/*Baglan Dbye cek product ekle dictonarye

_ProductCache.Add(ID, _product);

return _ProductCache[ID];

Builder Pattern'i temel olarak, karmaşık constructor yapısına sahip nesnelerin ayrıştırılmasına yardımcı olan design patternlerden birisidir, nesne yaratılması sırasında aynı construction farklı kullanımlı nesne yaratılmak için kullanılır. Anlamı, nesnenin değerlerini constructor alarak nesneleri uygun olarak oluşturur. Örneğim bir pizza siparişi alan, pizzayı türüne göre üreten ve teslim edilen süreçin örneğidir.

namespace BuilderPattern

//Temel Pizza Nesnem

public class Pizza

public Pizza()

public string Hamur;

public string Sos;

public string Malzeme;

public void SetHamur(string h)

public void SetSos(string s)

public void SetMalzeme(string m)

//Pizza yapıcım

public abstract class PizzaBuilder

public PizzaBuilder()

protected Pizza _Pizza;

public Pizza GetPizza()

return _Pizza;

public void CreateNewPizza()

_Pizza = new Pizza();

public abstract void buildHamur();

public abstract void buildSos();

public abstract void buildMalzeme();

//Pizalarımı nasıl yapıcağım :)tarifleri

public class TurkishPizza : PizzaBuilder

public override void buildHamur()

_Pizza.SetHamur("InceHamur");

public override void buildSos()

_Pizza.SetSos("Chilli Sos");

public override void buildMalzeme()

_Pizza.SetMalzeme("Mantar+Pastırma+Mozzarella+Zeytin");

//Pizalarımı nasıl yapıcağım :)tarifleri

public class ItalianoPizza : PizzaBuilder

public override void buildHamur()

_Pizza.SetHamur("DublexHamur");

public override void buildSos()

_Pizza.SetSos("Hardal Sos");

public override void buildMalzeme()

_Pizza.SetMalzeme("Siyah Zeytin+Mozzarella+Küp Sucuk");

//Sipariş alan ve Pizzayı veren vatandaş :)

class Garson

private PizzaBuilder pizzaBuilder;

public void setPizzaBuilder(PizzaBuilder pb)

public Pizza GetPizza()

return pizzaBuilder.GetPizza();

public void PizzaHazirla()

//Kullanımı

public class Program

//Sipariş 1 Turkish pizza siparişi

public static void Main(string[] args)

Garson g = new Garson();

PizzaBuilder turkishPizza = new TurkishPizza();

Pizza p = g.GetPizza();

Console.WriteLine(p.Malzeme + " " + p.Hamur + " "+p.Sos);

Console.Read();

public static class EntityFactory

public static T CreateEntity<T>() where T : new()

//Nesnemizi yaratalım

T t = new T();

return t;

 

internal static class ObjectCloner

public static object Clone(object obj)

{

using (MemoryStream buffer = new MemoryStream())

{

BinaryFormatter formatter = new BinaryFormatter();

formatter.Serialize(buffer, obj);

buffer.Position = 0;

object temp = formatter.Deserialize(buffer);

return temp;

}

}

The Open Close Principle (OCP)

Uygulamamizin entity katmanin genişletilmeye açik ama değişikliğe ve silmeye kapali olmasi prensibidir.Bu her ne kadar da imkansiz olsa da değişiklikleri minimum düzeye indirecek önlemleri almaliyiz.

kapali tutmanin iki yolu;

1-Abstraction kullanmak. Değişiçek kisimlari soyutlayarak isole etmek

2-Data Driven yaklaşimi

Liskov Substitution Principle (LSP)

Base class a point eden fonksiyonlarin türeyen class lar üzerinde çalişmasini sağlama prensibidir.

Yani base class i kullanan fonksiyolarin base class yerine türetilen class i da kullanmasi sağlanmali.

Bu problemden kurtulmanin yolu da fonksiyonu detaylardan abstract etmek.

Fonksiyonun üzerinde işlem yaptiği tip olarak öncelikle üzerinde çaliştiği tipi görmeli.

Heuristic and Conventions

Bütün member lari private yap,encapsulation genelde sağlamak.

Global değişken kullanmaktan kaçin:Değeri her an heryerde değişebilen global değişkenler programin olmadik yerlerinde olmadik şekilde etkide bulunabilirler

Stability Dependencies Principle (SDP)

 Yapilar arasindaki ilişkiler bu yapilarin stabilitesini bozmamali.Yapilar kendilerinden daha kararli olan yapilarla ilişkilenmeli.

The Stable Abstractions Principle (SAP)

Stabilite si fazla olan yapilarin abstraction i da fazla olmali.

Common Reuse Principle (CRP)

Bir yapi içindeki bütün class lari tekrar  kullanilabilir halde olmali ki herhangi bir class ta yapilan değişiklik yapinin yeni bir versiyonunu oluşturmuş olur.

The Reuse/Release Equivalance Principle (REP)

Bu prensip genelde bir uygulama üzerinde birden fazla takim çalişiyorsa kullanilir. System yoluyla released edilmiş componentler efektif şekilde kullanilabilir.

Common Closure Principle (CCP)

Yapi içindeki class larin değişikliklerden etkilenmesini önlemek gerekir.Çünkü yapi üzerindeki değişiklik içindeki class lar da etkileyebilir.

The Acyclic Dependencies Principle (ADP)

Eğer birbirleriyle ilişkili yapilari olduğu gibi kullacaksa dependency ler en üstten yani roottan en alt kadameye kadar ayarlanmali.

The Interface Segregation Principle (ISP)

Kullanilacak memberlar (metotlar property ler  vs) gruplanarak yari ayri interface lere bölünmeli.Böylece class in kullanmadiği member lar implement edilmek zorunda kalinmaz.

Polyad  vs Monad

Objelerin Monad olarak (property ler grouplanarak içinde bulunduğu obje) fonksiyonda paramatre olarak verilmesi işlemidir.Objelerin Polyad(daha küçük yapilar olarak) fonksiyonlara parametre olarak verilmesidir.Böylece dependency ler de daha küçük ve daha kolay yapi korunumu sağlar.

Design pattern, yazılım dünyasında OOP temeline dayanarak, var olan ortak problemlere uygulanan çözümlerdir.  Basit bir örnek ile açıklarsak, bir nesnenin sadece tek bir instance oluşmasını istiyorsak(mdi form gibi), Singleton patterni bu probleme bir çözüm getirmiştir. Yazılım dünyasında logical çözüm geliştirmeden; çok tasarım tabanlı çözüm geliştirmeye amaç edinmesidir. Geliştirilen uygulamanın esnekliğine(flexible), tekrar kullanabilirliliğine (reusability) odaklanmasıdır. Dolayısı ile geliştirilen çözümü, tekrardan geliştirme, iyileştirme(improvement),versiyonlama süreçlerinde büyük avantaj sağlamaktadır. Yazılım süreçlerinde mimari açıdan büyük önem taşımaktadır. Geliştirilen uygulama bir takım tarafından geliştiriliyorsa, uygulama geliştiriciler tarafından da rahatlıkla konuşmayı ve anlaşmayı destekler. Biraz da araştırma sonucu design pattern tanımlarına bakalım.

Ekşisozluk:

nesneye yonelik programlamada ** sik sik karsilasilan program dizayn problemlerini tanimlayip, herhangi bir programlama dilinden bagimsiz olarak bu problemlerin cozumunu class,interface, subclass,method gibi temel oop elemanlari ve bu elemanlarin iliskileri cercevesinde ifade etmekte kullanilir design pattern'lar. software engineering'in heyecan verici konularindan biri olup, dogru durust anlasilirsa, programcinin isini oldukca kolaylastirir, yazilan kodun tekrar tekrar kullanilmasina* imkan saglayarak. ama bu konudaki kitaplarin, ozellikle de konunun islendigi en onemli kitap sayilan, gang of four'un yazdigi 'design patterns elements of reusable object oriented software' adli kitabin soyutlugu da meshurdur.

1.(willy van der kerkhoff, 14.04.2002 06:29 ~ 07.03.2006 21:11)

IBM T J Research / James W Cooper:

·         “Design patterns are recurring solutions to design problems you see

over and over.” (The Smalltalk Companion)

“Design patterns constitute a set of rules describing how to accomplish

certain tasks in the realm of software development.” (Pree 1994)

·         “Design patterns focus more on reuse of recurring architectural design

themes, while frameworks focus on detailed design and

implementation.” (Coplien and Schmidt 1995)

·         “A pattern addresses a recurring design problem that arises in specific

design situations and presents a solution to it.” (Buschmann et al.

1996)

·         “Patterns identify and specify abstractions that are above the level of

single classes and instances, or of components.” (Gamma et al., 1993)

But while it is helpful to draw analogies to architecture, cabinet making,

and logic, design patterns are not just about the design of objects but about

the interaction between objects. One possible view of some of these

patterns is to consider them as communication patterns.

Christopher Alexander:

"Each pattern describes a problem which occurs over and over again in our

environment, and then describes the core of the solution to that problem, in such a way that you can use this

solution a million times over, without ever doing it the same way twice"

Bir patterni oluşturan dört temel esas vardır; pattern ismi, problem, çözüm ve sonuç. Bu dört unsur, var olan problemler karşısında mantıksal çözümlerden ziyade tasarımsal esnekliği ve tekrar kullanımı yüksek çözümü yüksek olan patterni sunar.

Design Pattern temel yaklaşım olarak 3 ayrılır: creational(oluştursal ),structural(yapısal) ve behavioral (davranışal) patterns olarak.

a.       Creational(oluştursal) pattern: Doğrudan instance almaktan, herhangi bir method veya bir durum ile ilinti instance alınmasıdır. Hangi nesnenin varolan durum için oluşturulması gerektiğine karar vermede daha fazla esneklik kazandıran patternlerdir.

                                        i.            Factory Method

                                      ii.            Abstract Factory

                                     iii.            Builder

                                     iv.            Protoype

                                      v.            Singleton

b.       Structural(yapısal) pattern: hesap verileri yada karmaşık kullanıcı arayüzleri gibi durumlarda, nesne gruplarını daha geniş yapılar içerisinde düzenlememize yardımcı olan patterndir.

                                        i.            Adapter

                                      ii.            Bridge

                                     iii.            Composite

                                     iv.            Facade

                                      v.            Proxy

c.        Behavioral(Davranışsal) pattern: modeliniz içerisindeki nesneler arasındaki iletişimi ve akışın, karmaşık bir yapıdan kontrol edilebilir tanımlamanıza yardımcı olan patterndir.

                                        i.            Interpreter

                                      ii.            Template Method

                                     iii.            Chain of Responsibility

                                     iv.            Command

                                      v.            Iterator

                                     vi.            Mediator

                                   vii.            Memento

                                  viii.            Flyweight

                                     ix.            Observer

                                      x.            State

                                     xi.            Strategy

                                   xii.            Visitor

 Bundan sonraki yazılarımda bu patternleri teker teker inceleyerek, örnekleri ile sizler ile paylaşamayı planlıyorum.

class Program

static void Main(string[] args)

//Csharp + VBNET + JAVA => 1 + 2 +4

Language EnumToEnum = Language.CSharp | Language.VBNET | Language.JAVA;

//7

int EnumToInt32 = (int)EnumToEnum;

//Language.CSharp | Language.VBNET | Language.JAVA

Language Int32ToEnum = (Language)7;

[Flags]

enum Language

starbuzz cafee içinde, ürünlerin hepsi temel olarak kahveden türemektedir. Mocha, cafee late, espresso, americano... Bu durumda bir abstract class yazarak, ürünlerin hepsini burdan türetmek mümkün gibi. bir espresso,americano,cafelate alan adamın hesabı:)

namespace StarbuzzCofee

class Program

{

static void Main(string[] args)

{

Service s = new Service();

s.ServiceAdd(new Espresso());

s.ServiceAdd(new Americano());

s.ServiceAdd(new CafeLate());

s.ServiceAdd(new Espresso());

s.PaymentToServicedCost();

}

}

public abstract class Beverages

{

public Beverages()

{

description = "Bilinmeyen İçecek";

}

public string description;

public string getDescription()

{

return description;

}

public abstract double Cost();

}

//Temel kahve

public class Espresso : Beverages

{

public Espresso()

{

description = "Espresso";

}

public override double Cost()

{

return 3D;

}

}

//Espresodan türeyen kahveler su ve espresso

public class Americano : Espresso

{

public Americano()

{

base.description = base.getDescription() + " to Americano";

}

public override double Cost()

{

return base.Cost() + 2;

}

}

//Espressodan türeyen late süt ve espresso

public class CafeLate : Espresso

{

public CafeLate()

{

base.description = base.getDescription() + " to CafeLate";

}

public override double Cost()

{

      return base.Cost() + 3.5D;

}

}

public class Service

{

private System.Collections.ArrayList Serviced;

public Service()

{

   Serviced = new System.Collections.ArrayList();

}

public void ServiceAdd(Beverages bv)

{

   Serviced.Add(bv);

}

public void PaymentToServicedCost()

{

double totalcost = 0;

foreach (Beverages bv in Serviced)

{

Console.WriteLine(bv.getDescription());

Console.WriteLine(bv.Cost());

totalcost += bv.Cost();

Console.WriteLine("--:--");

Console.WriteLine(totalcost);

}

Console.WriteLine("---------------");

Console.WriteLine("Total Cost :" + totalcost);

Console.ReadLine();

}

}

Program to an interface, not to an implementation, esnek (flexible), genişletilebilir (extensible) ve idare edilebilir (maintainable) yazılım yazmayı kolayylaştıran en önemli ilke olarak göze çarpıyor.

Duck örneği, bir oyun tasarlaması olarak ördek yazıdığımızı varsayalım. ve 9 davranışı farklı ördek olsun, genel davranışları ötmesi ve ucması. sözkonusu ördek için bir superclass yazıp her bir cesit içinde davranışları override etme işin için cıkılmaz ve zor bir yapıya götürüyor. ancak her bir davranışı(algoritmasını) bir interface ile classlara implement ederek tasarlarsak dizayn çok kullanışlı ve anlamlı olmaya başlıyor. Aşağıdaki örnek gibi

RedDuck x = new RedDuck();

public interface FlyAble

void fly();

public interface QuackAble

void Quack();

public class FlyWithRocket : FlyAble

#region FlyAble Members

public void fly()

Console.WriteLine("Roket Hızı ile ucuyorum");

public class NoFly : FlyAble

#region FlyAble Members

public void fly()

Console.WriteLine("Ucamıyorum");

public class FlyForNormal : FlyAble

#region FlyAble Members

public void fly()

Console.WriteLine("Normal Ucuyor");

public class quackOver : QuackAble

#region QuackAble Members

public void Quack()

Console.WriteLine("Vack Vırak");

public class quackMute : QuackAble

#region QuackAble Members

public void Quack()

Console.WriteLine("Ötemiyorum pıt pıt ");

public class RedDuck

FlyAble ucması;

QuackAble otmesi;

public void ucusu()

ucması = new FlyWithRocket();

public void otusu()

otmesi = new quackOver();