| Yazar |
|
dotnetonur
Dersaadet
Kayıt: 21.11.2007 |
|
Connection String`leri (bağlantı stringi, bağlantı katarı) merkezi bir yerde tutmanın birçok yararı vardır. Sistemin inşasından sonra veritabanının başka bir yere taşınması gibi bir durum söz konusu olduğunda, eğer bağlantı cümleciği tek bir merkezden sağlanıyor ise, bu merkezdeki cümleciği değiştirmek yeterli olacaktır. Ama bağlantı cümleciği her sayfada yinelenerek yazılıyorsa, veritabanının taşınması veya değişmesi esnasında sorun teşkil edecektir.
Çoğu ASP.NET programcıları tarafından bilindiği üzere, connection string`i Web.Config dosyasında saklayabilmekteyiz. Ama olur da global.asax dosyasında saklamak isterseniz, aşağıdaki gibi saklar ve kullanabilirsiniz.
//Bu kodu global.asax dosyasına yazacaksınız.
Application[“DBConnectionString”] = “server=localhost; uid=sa; pwd=; database=veritabani”;
Yukarıdaki kodu global.asax dosyasına yazdıktan sonra, bağlantı cümleciğinize aşağıdaki şekilde istediğiniz sayfadan ulaşabilirsiniz.
String strConnectionString = Convert.ToString(Application[“DBConnectionString”]);
http://www.asepedatnet.com/makale_goster.aspx?Id=58
Ortam sanal olsa da, islenen suc gercektir...
|
|
|
| Yazar |
|
orhan
istanbul
admin
Kayıt: 17.11.2005 |
|
burdaki "Application" tan kasıt "Application Scope" ise bunu değiştirmen tüm uygulamada Application[“DBConnectionString”] değerini değiştirmez mi? Öyleyse her sayfada dinamik olarak değişen [“DBConnectionString”] Session da durması daha mantıklı değil mi?
Application[“DBConnectionString”] şu değeri değiştiren fonksiyonun synchronized olması gerekir. Buda yüzlerce isteğin geldiği bir sunucuda Thread'lerin bu değişim işlemini beklemesi anlamına gelir. Bu da performansın düşmesine neden olur.
N/A
|
|
|
| Yazar |
|
mehmet
Antalya
Kayıt: 29.01.2006 |
|
web.config te durmasıyla global.asax ta durmasının farkı nedir ki. normalde web.config te duruyo zaten global.asax ta olmasının bize bir ekstradan yararı var mı?
Soldier of Fortune
|
|
|
| Yazar |
|
dotnetonur
Dersaadet
Kayıt: 21.11.2007 |
|
:)
Açıkçası bu makaleyi meraktan yazdım. Connection String`in Web.Config`den başka bir yerde tutulup tutulmayacağını merak ediyordum, tutuluyormuş :)
Global.asax`da tutulması performans kaybına neden olur mu bilemem ama bağlantı cümleciğiniz Web.Config`de ne kadar güvende ise, Global.asax dosyasında da o kadar güvende olur diye düşünüyorum...
Ortam sanal olsa da, islenen suc gercektir...
|
|
|
| Yazar |
|
tarikkranda
Kayıt: 07.01.2006 |
|
dotnetonur yazdi | | :)
Açıkçası bu makaleyi meraktan yazdım. Connection String`in Web.Config`den başka bir yerde tutulup tutulmayacağını merak ediyordum, tutuluyormuş :)
Global.asax`da tutulması performans kaybına neden olur mu bilemem ama bağlantı cümleciğiniz Web.Config`de ne kadar güvende ise, Global.asax dosyasında da o kadar güvende olur diye düşünüyorum... |
Öncelikle burda bir düzeltme yapmak istiyorum. Global.asax ile web.config birbirinden çok farklı kavramlar. Birisi normal bildiğimiz derlenerek çalıştırılabilir bir dosya iken, diğeri sadece bir konfigurasyon dosyasi. Siz burada connection string'i global.asax ta saklamıyorsunuz. Tahminimce global.asax içindeki metodlardan application start metodu içerisinde yaptığınız(nereye yazdığınızı belirtmediğiniz için tahmin yürütüyorum) bu işlem ile bir string cümleciğini tüm uygulamadaki sessionlar tarafından erişilebilen ve bunlara çatı gürevini ütlenen key/value tipinde bir koleksiyon olan Application sınıfının örneğine yazıyorsunuz. Dolayısıyla global.asax ta saklmaka diye bir ibare yanlış olur. Çünkü web.config de olduğu gibi kendisi bir konfigurasyon dosyası edğildir.
Diğer taraftan web.config de saklamanın avantajı, uygulamayı derlemeye gerek kalmadan veri tabanını değiştirmenize olanak tanır. Bu tarz değişiklikler için güzel bir seçimdir web.config. Ancak ben kişisel olarak kendi bağlantı cümleciklerimi ne web.config de, ne de global.asax içindeki application_start metodunu kullanarak Application'da saklıyorum. Ben bu işi Enterprise Library kullanıyorsam ordaki Data Access Layer'da ya da kendi geliştirdiğim Data Access Layer içinde bir sınıfta saklamayı uygun görüyorum. Bunun kendimce bulduğum nedeni şu, eğer serverdaki kullanıcım bir şekilde ulaşılırsa veya FTP den kaynaklanan bir açıkla uygulamama erişilirse bir saldırganın ilk bakacağı yer web.config dosyasıdır diye düşünüyorum. Çünkü buradan veri tabanının erişim bilgilerini, kullanıcı adı ve şifresini kolaylıkla elde etmek isteyecek ve esas hedef olan veri tabanına ulaşacaktır.
Ancak ben connection stringimi DAL içinde derleyerek sakladığım için ve obfuscator aracı ile mevcut DLL lerimi (ki bunu ASP.NET 2.0 otomatik olarakta yapabiliyor) karıştırdığım için işi biraz zora sokmuş oluyorum. Bu çok düşük bir ihtimal olsada hiç belli olmaz diyip, kelin ilacı varsa başıma sürerim diyorum:))
Diğer bir taraftan Application sınıfının örneğine veri yazıp okurken artık kilitleme mekanizması mı kullanırsınız, semafor mu kullanırsınız bilemem ama kesinlikle thread safe bir şekilde geliştirmeniz gerekmektedir. Application sınıfı thread safe bir sınıftır ta ki, siz gerekli önlemleri aldıysanız. Bu yönüyle Orhan'ın düşüncesi haklı. Ancak biz sadece okuma amacıyla kullandıgımız için Orhan eş zamanlı olarak erişimi serbest bırakabiliriz. Ancak dediğim gibi eğer uygulamamızın içerisinde başka yerlerde Application a başka degerler atayacaksak (örnegin Application["Ziyaret_Sayisi"] = x + 1 gibi), o zaman thread safe hale getirip Lock mekanizması kullanırız bu da o anda Application içinden conneciton stringi çekmeyi bekleyen sayfaları yavaşlatır. Application sadece bu amaçla (connection string saklama) kullanılacaksa sorun olmaz ama gereksiz bir kısıtlama yapmış oluruz.
Ve son olarak Orhan'ın söylediği session olayına biraz açıklık getirebilmeyi dileyerek;
Burda connection string in sessionda saklanması diye birşey söz konusu olamaz Orhan, çünkü her sayfa aynı veritabanına bağlanıyor. Dolayısıyla session içerisinde aynı connection stringin birer kopyasını saklamış oluruzk, bu da Onur dediğinin sadece daha fazla maliyetli hali demektir. Yani sistemde o anda 1000 kullanıcı online ise gereksiz yere aynı stringin 1000 örneğini saklamış oluruz. dediğim gibi derleyip saklayın ya da web.config den devam edin ;)
Herkesin bayramını kutlar, mutlu bayramlar dilerim.
|
|
|
| Yazar |
|
orhan
istanbul
admin
Kayıt: 17.11.2005 |
|
benim bahsettiğim kısım dinamik olarak değişecekse sessionda set edilmesi daha doğru olabilir. Application[..] kısmının thread safe olma zorunluluğu framework içinde olmalıdır performans kaybı ordan olur.bu kodla erişip düzenlenecek bir alan değil. Tabi Application = application scop ise.
N/A
|
|
|
| Yazar |
|
tarikkranda
Kayıt: 07.01.2006 |
|
orhan yazdi | | | benim bahsettiğim kısım dinamik olarak değişecekse sessionda set edilmesi daha doğru olabilir. Application[..] kısmının thread safe olma zorunluluğu framework içinde olmalıdır performans kaybı ordan olur.bu kodla erişip düzenlenecek bir alan değil. Tabi Application = application scop ise. |
Öncelikle bu kısım dinamik olarak değişmediği için session burda anlamsız oluyor. Diğer taraftan Application sadece tüm uygulamadaki sessionlar tarafından erişilebilen global bir nesneden ibaret, application scope ile farklı yani, dolayısıyla buna yazma işlemlerimizi thread safe hale getirmeliyiz. Framework bu konu ile sadece Application sınıfını thread safety destekler halde tasarlayarak verebilir programcıya, çünkü kitleme mekanizmasının getirdiği maliyeti de programcı kendi üstlenmelidir.
|
|
|
| Yazar |
|
orhan
istanbul
admin
Kayıt: 17.11.2005 |
|
application derken uygulama kastediliyor ben scope sanıyordum.
N/A
|
|
|
|
|
-
 Del.icio.us
-
 Digg
-
 Facebook
-
 Furl
-
 Google
-
 Blink
-
 Simpy
-
 Spurl
-
 Y! MyWeb
|
|
| | | | |
