Asp.net düşüncelerim karıştı 🙂

merhaba,

Yaptıgınız kodda ılk bakısta cok bır hata goremedım calısabılır. Fakat son cumlerınızı okudugumda zannedersem basvuru yaptıgınız fırmalar farklı teknoloıjıler uzerınde calısıyorlar

Onceden Asp.Net , SQL olarak adlandırılan yanı su anda sızın kodlarını paylastıgınız Klasik Asp.Net olarak adlandırılıyor .

MVC ise Model View Controller dediğimiz yeni bir pattern diyelim. Yani class yerine controller, aspx ascx yerine view , sql yada transact yerinede entity framework ile model geliyor.

Zannedersem size iş başvurusunda mvc ile ilgili yorum yapan firmalar hem sizin ilerlemenizi hemde şu anda sektörde mevcut olan yeni teknolojilere uyum sağlamanızı kod yazmaanızdan daha ön planda tutuyorlar.

O yüzden gittiğiniz her yerde MVC isteniyor olabilir. Hedeflerinize MVC ile alakalı da plan yapmanız bu durumda sanki daha doğru olacaktır.
Saygılar

Merhaba,

Her geçen gün gelişen ihtiyaçlar doğrultusunda mevcut pattern ve kütüphanelerin ihtiyacı görüp/görmemesiyle ilgili bir durum. IK ve iş görüşmeleri boyutunu ayrıca değerlendirmek gerek, fakat Asp.Net MVC kütüphanesi klasik webform mimarisinin birçok hantal yönünü ortadan kaldırmak üzere geliştirilmiş aslında yeni bilinen fakat geçmişi çok daha eskilere dayanan MVC patterninin bir uyarlamasıdır. MVC pattern'i yazılım geliştirmenin temel prensiplerinden SoC (Seperation of Concerns), IoC (Inversion of Control) prensipleriyle çelişmeyen bir mimariye sahiptir. Bu yüzden özellikle günümüz web geliştirme dünyasında çok popülerdir.

"Yukarıdaki kodda çalışıyor ne gerek var, Asp.Net WebForm'un neyi eksik?" diye soracak olursanız;

"Aslına bakarsanız yok, fazlası bile var denebilir." Asp.Net webform modern web uygulamalarına çok farklı bir yaklaşım getirmiştir. Eski bir çok soruna kabul edilebilir iyi çözümler sunmuştur. Fakat gerçekte durum biraz daha karmaşık. Getirmiş olduğu çözümlerin zamanla kullanımı arttıkça bazı sorunları da beraberinde getirdiği görülmüştür. Tabi bu eksiklik ve problemler zamanla kullanıcı deneyimleriyle ortaya çıkmış, gözlemlenebilmiştir. Bunlardan en temel bazılarını aşağıdaki şekilde listelemek mümkün:

• View State : View State olarak bilinen, istekler arasında durumları muhafaza etme mekanizması, client ve server arasında çok büyük boyutlarda veri transferine sebep oluyor. Bu veri boyutu, mütevazi bir sitede bile yüzlerce kb'a varabiliyor. Söz konusu bu veri yalnızca, gönderilmekle kalmıyor tekrar geri geliyor ve her istekte veri iletimindeki miktar katlanarak büyüyor. (Daha basit bir ifadeyle; sayfa içindeki tüm kontrollerin bir önceki durumu/verisi bu mekanizma ile sunucu ve istemci arasında gidip geliyor.) Bu uygulama sunucuları üzerindeki bant kullanımını artırdığı gibi, sitenin yavaş yüklenmesine sebep oluyor. Tek başına bu durum bile çağımızdaki internet kullanım oranı, toplumun tüketim biçimleri, gelişen teknoloji ve ihtiyaçlar göz önünde bulundurulduğunda kabul edilebilir değil. Çoğumuz internette dolaşırken biraz geç açılan bir site gördüğümüzde sıkılıp kapatıyor, alternatif başka bir linke geçiyoruz:)
• Sayfa Yaşam Döngüsü : İstemci tarafında tetiklenen ve sayfa yaşam döngüsünün önemli bir parçaşı olan Event'ler (olay) ile sunucu tarafındaki bu event'leri yakalayıp işleyen EventHandler dediğimiz yapılar arasındaki iletişimin çok aşırı derecede karmaşık ve bir o kadar da hassas olması Webform'ların en zayıf yönlerinden bir diğeri. Çok az geliştirici View State hataları olmadan çalışma zamanında bileşenlerin(kontrollerin) üzerinde düzgün bir şekilde değişiklik yapabiliyor ya da çok az geliştirici gizemli bir şekilde çalışmayan event handler'ları farkedebiliyor.
• Bileşenlerin Ayrımı : Asp.Net WebForm code-behind modeli, önyüz markup (html) ile uygulama kodlarını farklı bir dosyada ayırmıştır. Bu ayrım zamanında karmaşıklığı azalttığı düşüncesiyle oldukça alkış getirdi. Fakat pratikte; geliştiriciler önyüz kodları ile uygulama mantık kodları arasına data katmanı gibi (veritabanı kodları vs..) sunum katmanına ait olmayan kodlar yazmaya başladıkça büyük alkış getiren code-behind yapısı korkunç, içinden çıkılamaz bir hal almaya başladı / almaya devam ediyor.
• Bağımsız Html : Asp.Net WebForm markup dosyalarında bu kütüphaneye ait server kontrolleri yazılır. Bu kontroller arka tarafta .net kütüphaneleri tarafından bildiğimiz tarayıcıların anlayabileceği html kodlarına dönüştürülür. Fakat bu dönüşüm sonrasında üretilen markup çoğu zaman beklediğimiz html kodundan gereksiz bir çok kod barındırır. Asp.Net 4 versiyonundan önce genellikle bu çıktı kodu, web standartlarına uygun değildi veya bunlar üzerinde iyi bir CSS kullanımını zorlaştırıyordu. Ayrıca server kontrolleri js/css tarafından ulaşılması zor olan, tahmin edilmesi zor ve karışık ID değerleri üretiyorlardı. Her ne kadar .Net 4 ve sonrası sürümlerde bu problemler azaltılmış olsa da beklediğiniz HTML’i elde etmek halihazırda sıkıntılı olabiliyor. Bununla beraber gereğinden fazla üretilen html sayfa boyutunu ve dolayısıyla yüklenme süresini arttırabiliyor.
• Zayıf Soyutlama : Web Formları mümkün olduğunca HTML’i geliştiriciden gizlemeye çalışır. Yeni ve özel bir davranışı tanımlamaya çalıştığınızda, ister istemez bu soyutlama bozulur. Ki bu sizi postback event mekanizmasında ters mühendislik methodları kullanmaya ya da istediğiniz HTML’i elde etmek için absürd/manasız kodlar yazmaya iter. HTML5 ile gelen yeniliklerin kullanımı, SEO vb. çalışmalar için tam bağımsız HTML üretme gerekliliğinin önünde bu soyutlama mekanizması web uygulama geliştiricileri açısından sinir bozucu bir engelden öteye gidememiştir.
• Test Edilebilirlik Güçlüğü : Web formların bu zayıf soyutlama mantığı ve karmaşık düzeni birim testleri açısından uygunsuz durum teşkil ediyor. TDD (Test Driven Development) Test güdümlü geliştirme prensiplerinin uygulanmasına, bileşenlerin bağımsız test edilebilmesine engel oluyor.

Özetle; yazılım geliştirme dünyasının büyük çoğunluğunca kabul görmüş, yeni sayılamayacak kadar eskiye dayanan bir mimariye adapte olma, yorum katma, geliştirme, güçlendirme yaklaşımının daha faydalı olacağı kanaatindeyim. IK konusuna değinecek olursam; günümüzde halihazırda webform altyapısında olan/geliştirilmeye devam eden sistemler olduğunu düşünecek olursak endişelenmeni gerektiren bir durum henüz yok görünüyor. Öte yandan bir vadede webform'un Microsoft desteğini yitirmesi ve beraberinde bu altyapıyı kullanmaya devam eden uygulama sayısının gün geçtikçe hiç denecek kadar azalması kaçınılmaz. (Gerçi php tabanında sistemlerin halihazırda var olması da bu görüşle tezat oluşturuyor ama o tarafta farklı dinamikler var buna engel olan)

Yenilikleri yakalamak ve sürekli kendimizi güncel konularda geliştirmek sektör çalışanlarının olmazsa olmazı. Yeni teknoloji ve alt yapılar her geçen gün daha büyük bir ivme kazanıyor. Takip etmek, yakalamak zor, ve daha da zorlaşacak...

Avni bey teşekkürler yazdığım klasik aspx kodları !

bu kod yapısı ile yedi tane proje yaptım admin panelli

site giriş aktifleri günlük 2000 ortalama

admin panel girişleri günlük 3 kişi aktif kullanımlı olarak 

Bu kod yapısı patlamadı (ukalalık olarak algılamayın lütfen)

kusura bakmayın biraz feryat figan eder gibi yazdım.

Mvc ye Bir şekilde geçiş yapacağım üzerinde çalışıyorum 

teşekkürler tekrardan

Merhaba Jian bey kusura bakmayın biraz feryat figan eder gibi yazdım. 

Evet yukardaki yazmış olduğunuz konulara katılıyorum webform, postback, yaşam döngüsü 

Benim yazdığım kod sistemimde de sayfalar postback oluyor yani contrellerlar sayfa yüklemesinde serverda her seferinde oluşturuluyor ve yükleniyor. 

Bu kod yapısı ile 7 proje yaptım ve sayfa açılış hızları çok ciddi olarak hızlı gelmektedir. (Ukalalık olarak düşünmeyin lütfen)

Bu siteleri dışardan bağımsız kişilere test ettirdim. Hepsinden çok hızlı açılıyor nasıl oluyor gibi bi dönüş yaptılar.

Mvc konusu evet 1975 yıllına dayanan bir geçmişi var ve model view controller üçgeninde çalışmakta çalışma mantığını anladım.

Mvc için kısa bir aylık kurs aldım geçişi hızlandırmak için konuyu buraya kadar getirdim 

Bundan sonra benim kafam karıştı kendi yazdığım kod yapısını mvc ortamına taşımaya başladım.

visual studio 2015 üzerinde çalışıyorum. 

Bu arada kısa bir wordpress geçmişim var ama php kodlama ile ilgili değil panel kullanımı plugin yükleme konuları

MVC Projeyi açtım açtıktan

1-)Bir sürü nuget paket yüklemesi yapıyorum ve sonra veri tabanı ilişkisi (foreign key constraint)  Javascript -- Css (bootstrap) -- entity framework -- dll üstüne dll yükleniyor. (kısa dan geçicem)

sonra ben add komutu ile insert yapıyorum işte bu noktada dağılıyorum.

1-) sql connection normal de app.config veya bir class içine yazılır güvenlik için

2-) entity framework yüklemesi bana sql bağlantısı için sadece webconfig üzerinden işlem yaptırıyor class ortamına taşıyamıyorum veri tabanı bağlantı hatası veriyor.

3-) Css yazarken projeye gerekli olanları kendim yazıyorum bootstrap içinde kullanmadığım bir sürü komut satırı var. (benim yazdığım 100 satır -- bootstrap 1000 satır)

4-)Proje içinde bir class içinde bütün işlemlerimi yaparken mvc ortamında model controller view üçgeninde buluyorum kendimi

5-)Mvc de add edit update gibi sayfaları view içinde kendi üretiyor ama ben tek sayfada islem.aspx üzerinde yapabiliyorum.

6-) Herhangi bir işlem yapmadan önce nuget paketi yüklüyorum sonra komutlarını yazıyorum (wordpress mantığı gibi)

7-)Eğer code first yerine database first seçersem bu seferde migration yapısı beni ciddi şekilde database tarafında kısıtlıyor.(Sql tablo üzerinde güncelleme ve sql server taşıma işlemlerinde...

😎 select - insert - update sorgularını ben server tarafında store procedure üzerinden yaptırıyorum. Mvc projesinde add update delete olarak yapıyor.

9-) ms sql server management --> SQL Profiler --> üzerinden sorgu sürelerine baktığım zaman 20 satırlık veri için

klasik aspx -- storeprocedure -- class -- 0,23 ms

mvc view -- controller -- model- code first - entity framework -- 0,69ms gibi bir rakkam çıkmakta.

10-) visual studio üzerinden proje derlenip çalıştırıldığı zaman diagnostic tools ekranında memory usage

klasik aspx -- storeprocedure -- class --0,90 mb

mvc view -- controller -- model- code first - entity framework -- 120-130 mb gibi rakamlar çıkarmakta

add komutunu arka kod kısmında inceledim aldığı değerlerin çoğu (uluslararası) boolen -- nvarchar(max) vb değer ler ben ise nvarchar(150) olarak veriyorum vs vs vs

Bu ana konularda düşüncelerim karışıyor ben neden mvc ortamına geçiyorum ve bu insanlar mvc'yi neden bu kadar istiyor. Gittiğim görüşmelerde de bunu tartışıyorum. :)))

Mvc nasıl bir sistem böyle sistem olur mu demiyorum yanlış anlaşılmasın konu lütfen ama bu kadar karmaşa içine girmek ve bu insanların bu sistemde ki bana göre hantallıklarını görmemesi ve yazılımcı olarak kendi yazmadığım bir select sorgusunu çalıştırmak bana mantıklı gelmiyor.

Ben kodu yazarken tabiri caizse dantel gibi işlemek isterim.

Bu düşünceden atamıyorum kendimi ya benim mvc yoluna girişim ve gidişim yanlış yada ben yazılımdan anlamıyorum 🙁

Bu arada zaman ayırıp okuduğunuz ve cevap yazdığınız için teşekküler.

Merhaba,

Tüm maddelere detaylıca cevap vereceğim, fakat hizlica anladigim kadariyla epey kafan karismis gorunuyor. Keza yazdigin maddelerin hicbiri asp.net mvc’nin konusu degil. VS Mvc template’inden bir proje olusturmussun ve bu template beraberinde bootstrap, ef, scaffolding,owin vs.. bircok kutuphaneyle birlikte geliyor. Bu template isini kolaylastirmak hizlica bir urun ortaya cikarmak icin hazir yapilarla geliyor. Elestirilerinin bircogu mvc patterni ile ilgili degil ve hakli oldugun noktalar var. Hepsinin de bir cozumu var. Vakit bulunca detayli olarak madde madde aciklamaya calisacagim.

Gorusmek uzere...

Tekrar Merhaba,

Bir önceki cevabımda bahsettiğim gibi yukarıdaki maddelerde bahsettiğiniz konular MVC ile ilgili değil. VS ortamında yeni bir web projesi oluşturmak istediğinizde 'Empty' seçerek sizin ihtiyaçlarınıza uygun inşa edebileceğiniz boş bir proje oluşturabilirsiniz. Bu durumda yukarıdaki maddelerde bahsettiğiniz hiçbir durumla karşılaşmazsınız. Empty tercihi haricinde yapacağınız seçimlerde VS sizin için hızlı ve kolay bir şekilde ürün geliştirmenize yardımcı olmak adına bazı hazır kütüphane ve componentleri beraberinde projeye dahil ediyor. Nuget üzerinde belli paketleri projenize referans ekliyor, (veri alışverişi için EF bunlardan biri) ekliyor. Çeşitli js ve css dosyalarını sizin için hazırlıyor. Authentication için Owin kütüphanesini ekliyor vs...

Bunları kullanmak zorunda değilsiniz. Bu template başlangıç için bir web projesinin temel parçalarını sizin adınıza implement ediyor. Bu parçaların hiçbiri doğrudan MVC ile ilgili değil. Bunlar başlı başına ayrı birer kütüphanedir. Belirttiğiniz maddeler üzerinden tek tek gidecek olursak;

1- Kısmen doğrudur. Koda gömülü pek tercih etmeyiz genelde dışarıdan konfigure edilebilir yerde olmalıdır. Yine de sizin ihtiyaçlarınıza göre dilediğiniz gibi kullanabilirsiniz.

2- MVC ile ilgili bir durum değil. EF başlı başına ayrı bir kütüphanedir. Asp.Net MVC ile değil bir webform altyapısında da EF kullanabilirsiniz. Fakat sorunuza gelecek olursak; kod içerisinden connection set ettirmenin yolları var elbette, fakat EF modelinin kendi soyutlaması buna doğrudan müsade etmeyerek doğru bir yöntem izliyor. Bir önceki maddede belirttiğim gibi web.config üzerinden kullanımı daha doğrudur. İllaki kod içerisinden başka bir yolla connection string göndermek isterseniz; DBContext nesnesini kalıtarak belli başlı ana akışlarda kontrolü ele alabilirsiniz.

3- Bootsrap kütüphanesi de MVC'nin bir parçası ya da zorunlu koşulu değldir.. Mobil duyarlı web arayüzleri geliştirmek adına hayatı kolaylaştıran kütüphanelerden biridir. Evet css ve js satır sayısı bir miktar büyüktür. İhtiyaçlarınıza göre bootstrap js/css dosyaları ayrı ayrı da projenize dahil edebilirsiniz. Kullanmadığınız kısımları kontrollü bir şekilde kaldırabilirsiniz.

4- Bu noktada çok fazla yorum yapılabilir. Fakat kısaca tek bir class'a çok fazla sorumluluk vermek istemediğimiz bir durumdur. Bu bağımlılıkların ayrıştırılması, sorumlulukların ayrıştırılması prensiplerine uygun değildir. Bunu ister webform, ister MVC ister başka bir uygulamanızda kod geliştirirken aklınızda bulundurmanızı öneririm. Her bir nesne kendine ait az sayıda sorumlulukla yüklenmelidir.

5- Bu Visual Studio Scaffolding mekanizmasıyla ilgilidir. Bir controller oluşturulduğunda işinizi kolaylaştırmak adına ve belli başlı temel prensiplere uygunluk açısından bu model, view'ları oluşturup EF ile ilişkili işlmeler kodunu sizin adınıza hazırlıyor. Kullanmak zorunda değilsiniz. Kendi action, view, model yapılarınızı kurabilirsiniz. Tek bir view içerisinde bahsettiğiniz tüm akışları gerçekleştirebilirsiniz. Bunun önünde hiçbir engel yoktur. İsterseniz tek bir controller ve hatta tek bir action/view üzerinden tüm sayfalarınızı oluşturabilirisiniz. Fakat bu yine çok fazla kodu tek bir yerde toplamak anlamına gelir. Bir çok açıdan bunu istemeyiz. En basitinden okunabilir ve anlaşılabilir bir kod olmaktan çıkar. Bu uygulamanın tabanı da MVC olmaz:)

6- İhtiyacınız olan tüm referanslar default projede gelir. Harici paketler nuget ile yüklenir. Bunda bir sorun göremiyorum. Bu konu da MVC ile ilgili değil, paket yönetimi VS'da oluşturacağınız tüm projelerde böyledir. Dilediğiniz gibi kullanmadığınız paketleri kaldırabilirsiniz, bunun önünde bir engel yoktur.

7-8 EF kullanıp kullanmamak sizin elinizde. MVC'i ile ilgili bir durum değil. DB işlemlerini istediğiniz gibi yapabilirsiniz. Şimdi olduğu gibi ADO.Net nesneleriyle veri alışverişini yönetmeye devam edebilirsiniz. MVC veriyi nereden getirdiğinizle ilgilenmez. Default template ile gelen veri altyapısını kullandığınız için MVC ile ilişkilendirmişsiniz her konuyu.. EF kullanmayı tercih ederseniz; elbette bu sevideki her kütüphanede olduğu gibi belli başlı bazı kurallar olacaktır. Eğer bu kütüphanelerden faydalanmak istiyorsanız bu kurallara uymak durumundasınız. Bu kuralları kısıt olarak algılamayın. Nesne yönelimli programlamanın temel yapıtaşlarından soyutlama ve kapsülleme ile ilgili bir durum bu. Sadece EF  ya da MVC ile karşınıza çıkmayacak..

9-10 Bu karşılaştırmalar farklı projelerde farklı sonuçlar verebilir. Bu tamamen implementasyonla ilgilidir. Bunlar sizin veri yapınızın bu kütüphanelere uygunluğu ile ilgili de olabilir. EF yalın olarak kullanıldığında bazen bu şekilde sonuçlar verebilir, bu da normaldir.. Sizin adınıza tüm veritabanınızı koda döken(yada tam tersi) bir kütüphaneye yardımcı olmanız gerek. EF dışarıdan sql ya da stored procedure çalıştırmanıza olanak tanıyor. Daha detaylı incelemenizi ve performans arttırıcı yönergeleri uygulamanızı öneririm. Tabi ki kendi sorgularınızı kendiniz yazabilir burdan daha fazla performans elde edebiliyorsanız, bu şekilde devam edebilirsiniz. Fakat EF ve diğer kütüphanelerde sadece performans kriterine göre kullanıp kullanmayacağınıza karar vermemeniz gerekir. Diğer kriterleri de göz önünde bulundurmak gerekir. Kod geliştirme hızı mesela;

Sonuç olarak;

Geliştirmiş olduğunuz sistemlerde son kullanıcı isterlerini karşılayabiliyor, gerek ve yeter koşulda performans elde edebiliyorsanız ve bundan memnunsanız aynı altyapıyla yeni ve devam eden projelerinizi geliştirmeyi sürdürebilirsiniz. Bu sizin tercihiniz. Herkesin MVC'e geçmesi gibi bir kaide yok:) Benim tespitim sizin de MVC mimarisini 3 katmanlı (Veri, İş, Sunum) uygulama mimarisiyle karıştırıyor olduğunuz yönünde. Bu çokça düşülen bir yanılgıdır. Gerçekte yaklaşım bu şekilde değildir. Asp.Net MVC yalnızca sunum ile ilgilidir. Model sizin DB nesnelerinizin karşılığı değildir. Controller sizin iş katmanındaki bir nesneniz değildir.  MVC hakkında daha fazla inceleme yapmanızı öneriyorum. Zamanla taşlar yerine oturacaktır. Tabii diğer kavramları içine dahil etmeden çalışma şeklini daha detaylı öğrenmeniz gerekir. EF, Bootstrap vs.. gibi konuları karıştırmadan modeli benimsediğinizde MVC'nin ne gibi kolaylıklar getirdiğini rahatlıkla görebilirsiniz.

Umarım faydalı olmuştur. İyi akşamlar.

Merhaba zaman ayırdığınız ve desteğiniz için teşekkürler

Ben galiba MVC konusuna yanlış yerden başladım ve yorumladım.

MVC = code first - database first - entity framework - bootstrap --> öğle bir bağlamışlar ki konuyu sanki mvc bunlar üzerine kurulmuş gibi

Bir çok makale ve video izledim fakat hiç birinde sizin dediğiniz gibi empty proje açıpta işlem yapan yok gibi herkez paketler yüklüyor ve bu paketlerden gelen hazır kütüphaneler üzerinden işlem yapıyor. Doğru yanlış tartışılır.

Benim yazdığım kodlama başlangıcında empty website veya projeye göre web application + object oriented yapısını boş olarak kullanıyorum hazır yapı kullanmıyorum. (lambda sorgularını hiç kullanmadım).

İhtiyaca göre kendim yazmayı daha uygun buluyorum kendi bakış açım.

Her programcının - yazılımcının kendi yorumunuda koda dahil etmesi ve özgün olması taraftarıyım.

Kurs döneminde de ilk yaptığımız yukarıda bahsettiğim paketleri yüklemek sonra proje geçmek oldu.

Mvc konusunu bir kaç yazılımcı arkadaşım ile görüştüm kısaca konuyu özetlersem bu kadar uğraşmana gerek yok yaz geç adamlar yazmış sen tekrardan neden bu kadar uğraşıyorsun gibi oldu bu noktada düşünceler ve mantık karıştı :))

Konuyu uzatmadan ve sizinde çok zamanınızı almadan :)))

Yardımlarınız için teşekkürler MVC araştırmalarını belirtiğiniz gibi yapacağım.

Taşlar yerine oturacaktır diye düşünüyorum.

Saygılarımla

Bir miktar yönlendirebildiysem ne mutlu. Farklı kavramlarda bogulmadan yalın mvc bilgisini gelistirmek icin empty projeden kendi yapinizi kurabilirsiniz, yoksa elbette baslangic template’i hizlica baslamak icin ideal bir secim olur.

iyi calismalar, kolay gelsin.

Başlangıç template durumunda mantık karmaşası oluyor. Evet bakıldığı zaman kolay ve iki satır ile bir çok şeyi kısa zamanda halledebiliyorsunuz.

Ama ben verinin nereden geldiğini ve nereye gittiğini hangi yolu izlediğini görmem gerek otomatik yapıda bulunan kütüphaneler beni bazı noktalarda kısıtlıyor. Verinin nasıl işlendiğini göre biliyorum ama müdahalle ettirmiyor.

Empty olarak başlamak benim için daha iyi olacaktır. MVC zaten object oriented mantığına çok yakın bir mantık ile ilerliyor. Mantık karışıklığı yüklenen paketlerde oldu.

Evet benim yazdığım yapı da bazı süre uzatan ve amelelik diye tabir edilen işler oluyor. Db tarafında bir kolon eklemek ve bunları classlara ekleme ve form üzerinde gösterme gibi bu konularda müdahale süreleri biraz uzuyor farkındayım.

Mvc - Entitiy Framework te bu konu kolay olarak yapılmakta models üzerinde bir değişken tanımla o migration ile arka tarafta ilgili yerlere eksin gibi bunların farkındayım.

Fakat ben db - class - web formları (html-code behind) oluştururken tek tek yazmıyorum :)))

Kendim yapmış olduğum bir program ile bunları otomatik olarak çıkartıyorum.

1-Sql tabloları

2-store procedureler

3- classlar

4- html - kod kısmı

5- aspx - code behind kısmı

Bu ana yapı oluştuktan sonra gerekirse ilgili yerlere müdahale ediyorum. Bir nevi entity framework mantığı ilkel versionu

Bu şekilde çalıştığım için hazır yapılar bana biraz karışık ve hantal geliyor.

Konuyu çok uzattım kusura bakmayın

Bu konuları internet üzerinde bir kaç kişi ile konuşmaya çalıştım fakat sizin gibi doğru düzgün bir şekilde konuşma fırsatım olmadı.

Empty ile başlayıp gerekirse hazır templatlere dönmek daha iyi olucak diye düşünüyorum.

Tekrardan teşekkürler