sorunsallar (1)
  • sık sık neden asp.net mvc kullandığımız soruluyor. ben de gizemli bir şeymiş gibi pek yazmamışım bu konuda. asp.net mvc, asp ve asp.net'teki sorunların tamamını çözüyor ve sql server ile diğer ikisi kadar uyumlu. bahsi geçen sorunlar neydi dersek liste çok uzun ama akla hemen gelenler:

    asp:

    - spagetti koda müsait - html koduyla business kodu içli dışlı - istesen ikisini ayırırsın ama elin de gitmiyo bu kolayına geldiği için.
    - dandik dil (vbscript) - performansı kötü - altındaki framework çok yetersiz (caching altyapısı yok, hashtable gibi basit yapılar için com objeleri üzerinden idareten çözümler gerekiyor) - rahatça genişletilebilir olmaktan uzak - tutarsız yığınla saçma şey. (asp'de jscript alternatifi var ama onda da başka şeylerde sıkıntı var - misal datediff, dateadd gibi sık kullanılan fonksiyonlar eksik - bazı sözdizimleri daha zahmetli - yığınla workaround gerektiriyor)
    - com tabanlı genişletilebilirlik yapısı deployment için tüm web uygulamasının kapatılması gibi sıkıntılı çözümler gerektiriyor.
    - 1997'den beri geliştirilmiyor - desteği de uzun vadede tamamen kesildiği zaman altyapıda çıkabilecek olası bir güvenlik açığının çözümsüz kalma riski var.
    - unit testing zor/zahmetli.
    - dahili url routing sistemi yok. o yüzden asp'nin adını değiştirmek tüm url yapını değiştirmek anlamına geliyor. restful url'ler için harici modüller gerekiyor. (ekstra konfigurasyon vs)

    düz asp.net (webforms):

    - leaky abstraction - yani web öğrenmek yerine webforms'un tag syntax'i ve tüm component'ların kendilerine has çalışma mantıklarını öğrenmen gerekiyor. ve bir yerde duvara toslarsan feci tosluyorsun çünkü kısıtlı bir kitlenin üzerinde çalıştığı teknolojide çözüm bulman daha da zorlaşıyor. bu kısmı bence asp'den de kötü. istesen her şeyi page_load'da yapıp bundan kurtulursun ama o zaman da aslında elde ettiğin asp'nin daha zahmetlisi oluyor.
    - yapı component kullanımında dahi geliştiriciyi page_load'a ve genel olarak business logic'i asp.net sayfalarının içine gömmeye itiyor. (sebebi sqldataadapter gibi component'lar. onlar ui tarafına yakın olunca sen de geri kalanını ui tarafına yakın tutma ihtiyacı hissediyorsun normal olarak)
    - bu yanlış yerlerden içiçe geçmeler sonucu business logc'in ui'la öyle içli dışlı oluyor ki geri kalan yerleri mock edip rahatça unit testing yapabilmek imkansızlaşıyor.
    - asp'deki gibi dahili routing sistemi yok.

    öte yandan asp.net mvc:

    - sana daha baştan view, controller, model diye hazır pişmiş faydaları kanıtlanmış bir katmanlama sunuyor. sana bir tek neyi view'a neyi controller'a neyi model'a koyacağını daha da önemlisi bu her katmanı ayırmanın ne sike derman olduğunu anlamak kalıyor. bir kere anladıktan sonra tüm mimari sana şu avantajları sağlıyor:
    - querystring/form parametrelerini işlemek son derece anlaşılır ve kolay bir modelle yapılıyor. (sanki bir fonksiyonu o parametrelerle çağırır gibi). o yüzden kodun içinde bunlara erişen doğruluklarını kontrol eden kod olmuyor (olsa bile çok kısa öz). onlar binder/validator yapılarıyla hallediliyor. koda baktığında ağaçlardan ormanı görme sıkıntın olmuyor. bu sayede controller'ları test etmek de kolay oluyor, request objesi oluşturacağına direkt fonksiyonu çağırıyorsun o kadar.
    - model üzerinden form gösterme, yollama ve teyid edip hataları kullanıcıya geri gösterme gibi son derece yaygın bir senaryoyu çok doğal ve rahat yollarla ve en önemlisi minimum eforla halletmeye yarayan bir altyapı sağlıyor.
    - mvc deseni doğası gereği ajax ya da api gibi alternatif içerik sunum yöntemleri sağlamayı basitleştiriyor.
    - önyüz ile business logic arasında net bir ayrım oluyor. bu sayede biri olmadan öbürünü test etmek mümkün oluyor. hatta bu sayede aynı altyapıyı tutup alıp başka bir projede (api, mobil vs) kullanabiliyorsun. nitekim beta'nın bize en büyük faydası da bu oldu.
    - asp/php gibi düz html üzerinde çalışıyorsun. sadece çok basit bir kaç helper'ı "dilersen" kullanma imkanın var. ama sonuçta xhtml'i sevmedin html5'e mi geçtin? webforms ekibinin html5 uyumlu component'lar çıkarması için 1 yıl beklemek veya aynılarının html5 uyumlularını yazmak için aylarca uğraşmana gerek kalmıyor.
    - .net framework ve c#'ın tüm güzellikleri elinizin altında. (asp'den geçenler için)
    - razor ile html şablonları diğer şablon yapılarına göre daha okunaklı.
    - routing (hangi url'e gidince ne yapılacağı) projenin kendisi tarafından tanımlanıyor. böylece başka alakasız bir modülün konfigürasyonu ile projeyi senkronize tutmak gibi son derece gereksiz bir efordan kurtuluyorsun.

    kısaca asp.net mvc web'deki ana senaryoların "sunucuya istek yollama", "html basma" ve "sonuçların doğruluğunu teyid edip kullanıcıya gösterme" olduğunu başarıyla tespit etmiş, "unit test edilebilirlik"i de farz kabul etmiş. o yüzden sağladığı tüm altyapı genişlemeleri de bunun üzerinden hayat kolaylaştırıcı şeyler. bu da olayın aslında asp.net mvc'de değil, mvc mimarisinin kendisinde olduğunu daha iyi netleştiriyor. ruby on rails gibi diğer mvc framework'leri de bu kafayla çalışıyorlar. hatta düz asp için bile mvc framework'leri var. o açıdan asp.net mvc, bu deseni başarıyla implement etmiş bir üye sadece ama sırrı desenin kendisinde yatıyor.
  • kaliteli bir web geliştirme platformu. büyükçe bir yazılım işini bununla hallettikten sonra hakkında bir şeyler yazma ihtiyacı duydum.

    evvela mvc'den önce microsoftun diğer web geliştirme platformuna bakalım. web forms'un mantığı şuydu: her şeyi kocaman bir form içine alayım, zira nasıl olsa kullanıcı bana veri gönderir bir şekilde, bütünleşik ajax sunarım siz java scriptle vs ile uğraşmayın, şu düğmeye basılı, bu checkbox seçili bilgisini viewstate adındaki kriptoyla htmlin içine gömerim. tablo yazdırmak, divleri kaldırmak için türlü türlü atraksyonum var (panel, gridview vs.), html değil bunları yazın işinizi halledin.

    bu durumda ssg'nin de dediği gibi,
    - sitenin görünümü html 5'e (veya daha yeni bir teknolojiye) geçtiğinde, webformun içine yazdığımız <asp:gridview> objesi yine kendi bildiğini yazmaya devam ettiği için sıçıyorduk.
    - basit bir javascript kullanmak istediğimizde bütünleşik ajax/java kütüphaneleriyle uyumsuzluk çıkıyordu, webforms için yazılmış dll arıyorduk, bulamazsak sıçıyorduk.
    - her şey bir formun içinde olduğu için sayfamızda form kullanamıyorduk, iframe'lerin içinde tasarladığımız forma gelen veriyi esas sayfamızın codebehind'ına aktarmak için sessionlarda boğuşuyor ve çoğu zaman sıçıyorduk (webforms ile sayfadan ayrılmadan 3d secure pos kurabilenlere selam ederim).
    - her sayfanın kendi codebehind'ı olduğu için, namespace'lerde, solution içinde projelerle boğuşuyor, yazılım ekibine yeni biri dahil olduğunda sistemi anlatamayıp sıçıyorduk.
    - nesne yönelimli bir yazılım altyapısı kullanıyor dahi olsak, webforms bütünleşik bir veritabanından al -objeyi doldur - sayfada göster çözümü sunmadığı için, kendi her obje için data access layer'larımızı yazıyor ve codebehind'larda kullanmak üzere objeleri dolduruyorduk. tabii ki sql kullandığımız için ve bunlar birer string olduğu için sorgulardaki hatalar projenin build olmasına engel olmuyor ve günlerimiz debug'da heba oluyordu.
    - html öğelerinin dahi id'leri kullanılamaz durumdaydı, zira yayınlanma sırasında tüm id'ler viewstate'de kullanılabilmesi için server tarafından değiştiriliyordu.

    mvc'de ise:

    - model - view- controller net bir şekilde ayrılmış. ha bu demek değil ki view'lar %100 html ve 0 bussiness logic kod içeriyor. hayır, hala bulanık sınırlar var, obje listesini foreach ile dönerek yazdırıyoruz. ama yazdığımız kod html. döngümüz c#. başka hiçbir yerde kullanamayacağım <asp:gridview> ya da <asp:panel> değil.
    - yazdığım view kodu html olduğu için, viewstate belası olmadığı için javascriptime karışanım görüşenim yok.
    - tüm codebehind'lar controllerda toplanırken, aynı webform içine doldurduğumuz ve pnlx.visible=false yaptığımız paneller ise ayrı razor viewlar artık. her biri bir fonksyonla controller'dan çağrılıyor. daha derli toplu, hatta otomatik olarak nasıl erişeceğinizi gösteren commentlerle geliyor (comment takıntınız varsa seveceksiniz).
    - linq ve entity framework 5 gerçekten çok başarılı ve hızlı. eğer yeni projeye başladıysanız, oluşturduğunuz objeleri veritabanı tablolarına ve veritabanına dönüştürüyor. mevcut bir veritabanınız varsa, objeleri ve aralarındaki ilişkileri kuruyor. işin arka planında sizin yazdığınız linq sorgusunu (ki ben lambda kullanıyorum) mvc stored procedure haline getiriyor ve siz arkaplanda ne olduğunu anlamadan objeniz ilintili objelerle birlikte dolmuş kullanıma hazır geliyor (sanırım eski versyonlarda linq üzerinden joinlemek gerekiyormuş bağıntılı objeleri almak için, şimdi lazy loading default geldiği için suser objesini doldurduğunuzda suser.entriler[0].entry gibi ona bağlı şeyler de otomatik geliyor.)
    - viewstate olmadığı için html id'lerine özgürlük geliyor.

    bunlardan gayrı asp.net mvc'nin sevdiğim özellikleri;

    - objelerinize özellikler vererek ([required], [key] vs. gibi) hem tablolarınızın doğru oluşturulmasına hem de view'larınızda obje doldururken yapılacak kullanıcı hatalarına karşı otomatik uyarılar oluşturuluyor.

    - aynı özellikleri action'larınıza da verebiliyorsunuz, login gerektir, sadece post'la çalış get'le çalışma gibi ([authorize], [htmlpost]). böylece basit kod yükünü üzerinizden almış oluyor mvc. kendi action filter'larınızı da yazabiliyorsunuz tabii (sanırım bu da 4. versyonla geldi).

    - mvc 4'le gelen bundling(css ve js dosyalarınızı küçültüp tek dosya haline getiriyor), routing'in(url yönlendirme) ve dbınit (yeni bir projede objeleriniz değiştikçe veritabanınızın otomatik değişmesi/her değişimden sonra örnek verilerin eklenmesi)fonksyonlarının global.asax'dan çıkıp ayrı bir klasörde toplanması

    - pm-console. veritabanında bir değişiklik yapmanız gerekiyorsa (örneğin bir tablonuza sütun eklenecek), objenize eklemeyi yapıyorsunuz, add-migration "son-güncelleme" ve update-databe komutlarını giriyorsunuz veritabanınız hazır. üstelik veritabanında ne yaptığını migrations klasörü altında son-guncelleme.cs altına kaydetti inceleyin diye.

    kusurları:

    - linq/lambda & entity framework "spagetti koda" çok müsait. controllerlar db query'lerle doluyor. projenin büyüklüğüne göre farklı türden db repository'leri yapmak gerekiyor. basit dbrepo mantığı bütünleşik gelse de çok katmanlı dal (data access layer) 4. sürüm itibariyle hala elle yazmayı gerektiyor. parametrik tek katmanlı bir dbrepo yapmayı denedim (dışarıdan obje türü alan create,delete,update db fonksyonları) ancak işler her zaman crud'la(create read update delete) bitmiyor.

    - linq/lambda & entity framework ince ayar istiyor. lazy loading otomatik olarak fazla veri çektiği için db fazla cpu/ram harcıyor, farklı db acsess türleri var elbet projenin farklı yerlerinde kullanılabilecek. çözümü sql server için profiler ve db tuning database advisor. sanırım postgre için de benzer profiler/tuning programları var. baktınız cpu'nun ateşini alamıyorsunuz, sql string çalıştırma imkanı da vermiş entity framework (denemedim ama yine de otomatik oluşturduğu stored procedure'lerden hızlı/verimli olmaz diye düşünüyorum).

    - otomatik oluşturulan razor view'larının şablonu değişmiyor, oluşturduktan sonra değiştiriyorsunuz istediğiniz gibi (bu en saçma kusuru sanırım mvc'nin. elimizdeki layout'a göre sürekli oluşturlacak default view'lar yapabilmeydik. nasıl değiştiğini bilen varsa haber etsin.)

    akıllara gelen ilk soruyu da yanıtlamak lazım tabii. "acaba yanlış yerde miyim? facebook bile php ile geliştirilirken benim işim ne asp.net mvc ile?"

    asp.net mvc bir araçtır, php de bir araçtır, sidik yarışına gerek yok. hangisinde kendinizi daha iyi ifade ediyorsanız, hangisinde işinizi en kısa sürede en az hatayla bitirebilecekseniz onu kullanın. ama asp.net mvc güzel ve kolay, deneyin derim.
  • "eğer iyi bişi olsa herkes web forms kullanmazdı. çıkalı 10 yıl olmuş, 10 yılda 1. olurdu. hiçbir yerde adam akıllı dökümantasyonu yok."

    evet, bugün asp.net mvc hakkında bu yorumu duydum. bu ve bunun gibi yorumları yapabilecek mantıkta insanların genel olarak piyasa şartları nedeniyle asp.net kullanmaları beni asp.net'ten soğutuyor. çünkü bu tarz adamlarla muhattab olmak istemiyorum. bu konuda da çok eminim ki yalnız değilim. bilgeadam gibi kursları bitirip ezberlediği şeylerle bir şeyler yapabildiğini görünce kendini ilah sanan mantıklar bunlar.

    piyasanın 2. devi php'de de durum çok farklı değil aslında. ama en azından "bak sürükleyip bırakıyosun al sana buton" diyen adam pek olmuyor.

    şu lanet olası eğitim kurumlarındaki eğitmenlere rica ediyorum. konuya girmeden önce programlama dili, framework, ide vb. kavramları öğretin öğrencilerinize. zarar etmezsiniz.

    neyse be amına koyim konu dışına çıktık fazlasıyla. eyyorlamam bu kadar.

    edit: yorumu yapan şahış asp.net web forms kullanmaktadır.
  • nerdeyse asp.net'in butun yanlislarini duzeltmistir.
  • web forms mu kaldı amk dedirten framework.

    (bkz: .net core)
  • asp.net mvc ancak bir şaka olabilir zira asp.net'in başat olanakları ve microsoft'un tavsiye ettiği, bu olanaklar ile üretilmiş çözümler, mvc'nin çok önceleri cevap olduğu katmanları birbirlerinden ayırma meselesine daha iyi ve daha kolay bir çözüm olarak sunulmuştu. ama anlaşıldı ki ne codebehind tasarım ile kodu gerçekten birbirinden ayırıyor ne de typed datasetler veri erişimine ilaç oluyor. yani projelerin kapsamı asp.net'in on dakikalık videolarını aşınca işler karışıyor, programcı bunalıyor. örneğin ruby on rails ile karşılaştırılınca asp.net'in ajax implementasyonu bütünüyle bir fiyaskodur. zira asp.net teknolojisi basit olması gereken yerde karmaşa, rahatlık vermesi gereken yerde sıkıntı yaratıyor.
  • asp.net'in ilk defa resmi olarak klasik "web formları" yürütme mantığının dışına çıkışı. 3.5 sürümüne eklenti olarak yayımlanacak. söylenene göre seçeneklerden sadece birisi olacak.

    güzel olan, asp.net mvc'nin ara katmanlarda, farklı alt sistemlerle çalışabilmeye imkan vermesi. meselâ view katmanında brail kullanılabilir. model katmanında ise nhibernate. sizi ado.net entity framework veya web formları kullanmaya zorlayan yok.

    öte yandan bir soruya verilen cevapta, klasik web kontrollerinin yanında mvc için de ek kontroller veya kontrol hazırlayıcılar sunacaklarını belirtiyorlar.

    .net dünyası için olumlu bir gelişme olarak not düşüyoruz. (bkz: http://www.evcil.net/tag/asp.net mvc/)
  • asp.net mvc 3 ile birlikte artik asp.net webforms ile uygulama gelistirenleri anlayamamami saglamis bir web altyapisi. ozellikle mix11 da piyasaya surulen tools update ile birlikte cok daha kolaylasmistir.
    microsft icin artik web recetesi; jquery + knockout js + asp.net mvc 3 haline gelmistir.
  • (bkz: asp'yi bitirdiniz, web forms'u harcadiniz, mvc'yi yedirmeyiz)
  • öğrenmeye başladığımdan bu yana 1 hafta kadar geçmiş bir web frameworkü. bu entry altında bazı temel şeyleri not almak isteyerek giriyorum çünkü ingilizce eğitim videolarını izlerken, dil bilginiz çok iyi değilse bazı şeyleri kaçırıp, sonrasında kaçırdığınız bu şeylere anlam verememek gibi şeyler yaşanabiliyor. doğal olarak bir kaç temel noktayı not alarak hem kendime hatırlatma yapmış olurum hemde belki başka kişilerde yararlanır düşüncesiyle buraya bu notları girmeye karar verdim. sonuçta malumunuz kutsal bilgi kaynağı.

    mvc- model view controller:

    daha önce web programlama ile biraz uğraştıysanız, mcv yapısını ille duymuşsunuz demektir.açılımı m(model) v(view) c(controller) şeklinde olan bu yapı özetle bir internet sitesinde görevleri 3 klasör altında mantıksal bir görevlendirme yapma yada dosyaları görevleri doğrultusunda gruplandırma işlemi.

    bu yapıya göre model sınıfı: proje içerisinde ihtiyaç duyduğunuz sınıfları temsil etmekte olup; örnek olarak, bir yemek sitesi için yemek sınıfını, sipariş sınıfı ve benzeri gibi projede kullanılacak sınıf modellerinin oluşturulup tutulduğu klasör oluyor.

    controller: projenizde back end işlemlerini yönettiğiniz, kullanıcıların yaptığı web isteklerine cevaplar döndürdüğünüz, veri tabanı isteklerini yönettiğiniz dosyalar grubu oluyor.

    view: bu dosya grubu ise kullanıcının gördüğü ve sitenizle etkileşime girebilmesine yarayan, controllerdan dönen modelleri kullanıcıya gösterebilmenize yarayan dosyaları ifade ediyor.

    özetle, bu mvc yapısı asp.net ve microsofttan bağımsız olan bir mantıksal gruplama işlemi. yani php ile bir internet sitesi geliştirirkende oldukça sık kullanılan bir yapı.

    asp.net mvc:
    asp.net mvc, işleri sizin için oldukça basitleştiren bir web framework. yani web geliştirmesi yapmanızı sağlayan ve normalde native dille yaptığınızda zorlayıcı olan işlemleri oldukça kolaylaştıran bir çatı.

    microsoft sitesi mvc linki ile microsoftun kendi sitesinde yer alan tutoriallara ulaşılabiliyorsunuz. ve küçük bir anektod olarak; ingilizceniz varsa ve microsoft default olarak ana dilinize türkçeye çevirirse, makeleyi ingilizce okumak için, linkte yer alan tr-tr olan dil parametresini en-us haline getirip ingilizce makeleye devam edebilirsiniz.

    asp.net temel klasörler ve dosyalar:
    ->app_start/routeconfig.cs: asıl yönlendirme dosyası, yani siteye giriş yaptığınızda url işlemine göre hangi controllerın hangi fonksiyonunun çalıştırılacağının tanımlı olduğu dosya.

    routes.maproute( name: "default", url: "{controller}/{action}/{id}", defaults: new { controller = "home", action = "ındex", id=urlparameter.optional );

    yukarıda ve aynı zamanda projenizde bulunan routeconfig.cs dosyasında yazan bu kod üzerinde de, görülebileceğiniz gibi siteye ulaştığınız urller; controller - action(controller içindeki fonksiyon)/ id şeklinde parçalanmakta ve buna göre size gerekli sayfayı size yönlendirilmesi yapılmakta.

    yani şöyle ki; localhost/controller/fonsiyon/değişken şeklinde bir link ile local internet sitesine girdiğinizde; bu url doğrultusunda, controller isimli controller dosyasına giriliyor, bu controller dosyasının içinde fonksiyon isimli fonksiyon çalıştırıp, size bu fonksiyon içinde bulunan işlemlere göre bir sonuç döndürülüyor.

    bu dönen sonuç genellikle, view klasörü içinde yer alan ve fonksiyon ismiyle aynı isimde olan bir razor sayfası oluyor ki şöyle bir link kafanızda bu sayfaların nasıl çalıştığını ve asp.net için web tasarımlarının nasıl uygulandığını anlamaya yardımcı olabilir: tr link en link

    yukarıda yazdığım routes.maproute... şeklinde olan kod asp.net mvc ile gelen default rota. buna ek olarak rotalar eklemek mümkün. şöyle ki;
    routes.maproute(
    name:"ısim",
    url:"domaindensonrayazılanklasor/{degisken1}/{degisken2}",
    default: new {controller="gereklicontroller",action="gereklifonksiyon"}
    };

    şeklinde kendimizde bir rota tanımlayabiliriz ve siteye domain.com/domaindensonrayazılanklasor/veri/veri şeklinde giriş olduğunda
    gereklicontroller -> controllerına gidilip, gerekli fonksyion degisken1, degisken2 isimli parametleriyle 2 veriyi alabiliriz.

    burda dikkat edilecek husus bu birden fazla rotanın sıralamasını iyi yapmak gerekiyor çünkü asp.net mvc ilk rotayı sınıyor,burada sınarken gerekli urli kıyaslıyor ve uygun bulursa yanlış rotaya sapabilir. eğer bulamazsa, bir sonraki rotaya bakılıyor. doğal olarak rota tanımlamalarını iyi yapmak gerekiyor.

    bundan daha kolay yöntem ise rota özelliklerini aktif etmek. bunun için,
    routes.mapmvcattributeroutes(); -> şeklinde bir komut eklememiz gerekiyor routeconfig.cs dosyasının içine. bunu yaptıktan sonra rota tanımlamalarını direk controller içerisinde action yani fonsiyon üzerine [route("domaindensonrayazılanklasor/{degisken1}/{degisken2}")] tanımlama yaparak, o action için gerekli parametreleri ulaşmayı sağlayabiliriz. yani bu yöntem ile route tanımlamayı direk controller içinde özellik tanımlayarak yapabiliyoruz.

    önemli sınıflar:
    actionresult sınıfı: controller sınıfları içerisinde fonksiyonların döndürdüğü sınıftır. genellikle 3 farklı kategoriden sonuçlar döndürür.

    1.content result: viewresult, partialviewresult, contentresult, fileresult, jsonresult, javascriptresult, emptyresult gibi bir içeriği, sayfayı yada dosyayı geriye döndürür.
    2.redirection result: redirectresult, redirecttorouteresult gibi farklı sayfalara yada controllerlara yönlendirme yapmamızı sağlar.
    3.status result: httpnotfoundresult, httpunauthorizedresult, httpstatuscoderesult gibi durumla alakalı bilgilendirme yapmamızı sağlar. yani sayfa bulunamadı, yetkiniz yok vb gibi hatalar döndürür.

    bir controller fonksiyonu içerisinde return httpnotfound(); -> şeklinde bir dönüş varsa ilk başta belirtilen şekilde url ziyaret edildiğinde ekrana bulunamadı sayfası basılır.

    return view(); -> aynı fonksiyon ismiyle kayıtlı .cshtml dosyası view/contolleradi.cshtml dosyası actionresult sınıfı olarak döner.
    yada
    return view("isim"); -> fonksiyon isminden bağımsız bir view/controlleradi/isim.cshtml dosyasını action result sınıfı olarak döner.

    return json(); -> diyebilmek için ise controller sınıfı içerisinde gerekli fonksiyon içerisinde bir değişken tanımlı olsun. örneğin;

    var nesne= new sınıf(){sınıfdegiskeni=deger;}
    return json(nesne, jsonrequestbehavior.allowget); -> şeklinde controller sınıfına yazarsak, kullanıcının get isteğine dönüş olarak json dosyası döndürülür ve json dosyasında nesne ve değişkenleri json formatında yazılı şekilde olarak http cevabı geri döndürülmüş olur.

    özetle actionresult özel bir sınıftır, çeşitli veri tiplerinden veriler döndürmemizi sağlar ve kullanıcının yaptığı isteğe http cevabı döndürmemizi sağlar.

    controllerdan - viewe veri aktarmak;
    controllerımızın içinde fonksiyonnumuzda tanımlı olan model sınıflarımızdan bir model tanımlayıp, model sınıfından olan bu nesneyi view içine vies(nesne); şeklinde yollayabiliriz.

    yolladığımız bu nesneyide view içerisinde kullanabilmek için, ilk satıra @model projeadı.....sınıf şeklinde tanım girdikten sonra, direk view içerisinde @model.değişken şeklinde değişkenimize ulaşabiliyoruz.

    layout kullanımı;
    layout kullanımı kısaca her sitede değişmeyen aynı kalan kısımların olduğu sayfadır. örneğin bir sitenin logosu, header kısmı hep aynı kalır ve o tüm sayfalarda değişmez. yada html kodlarınının head taglarinde bazı paremetreler dışında aynı kaldığından bunlarda değişmez. bunları tek tek tüm sayfalarda kopyamak yerine genellikle _ alt tire ile başlayan layout, çerçeve dosyaları oluşturuluyor.
    layout içeriği:

    <!doctype html>
    <head>
    meta bilgiler
    </head>
    <body>
    <div class="degismeyenheader">butonlar, logolar içerikler...</div>
    @renderbody() => bu fonksiyona dikkat önemli.
    <div class="degismeyenfooter">çeşitli linkler, içerikler, yönlendirmeler</div>

    </body>
    </html>

    bir sayfa için view dosyası oluşturduğumuzda yukarıda ki şekilde olan layout, bu view dosyası içerisine
    @{
    layout="~view/dosyayolu/_layout.cshtml"; =>burasıda önemli, layoutu bu değişkenle tanıtıyoruz.
    }
    <h1>sayfa başlığı</h1>

    bu view sayfası için controllerda sıkıntı yoksa, siteyi ayağa kaldırdığımızda, bize döndürülen html sayfası şu şekilde oluyor:

    <!doctype html>
    <head>
    meta bilgiler
    </head>
    <body>
    <div class="degismeyenheader">butonlar, logolar içerikler...</div>
    <h1>sayfa başlığı</h1> => @renderbody() olan yer yerine sayfa viewi içerisindeki html elementleri sayfaya yerleştirildi.
    <div class="degismeyenfooter">çeşitli linkler, içerikler, yönlendirmeler</div>

    </body>
    </html>

    peki layouta sayfa ile alakalı title, description vb gibi meta data bilgilerini nasıl göndericez ?
    bunun yoluda viewbag.isim="string"; şeklinde sayfa viewi içerisinde layout=yol; tanımlamasının üstüne yada altına (@{süslü parantez içerisine: viewbag.isim="veri";}) şeklinde bir atama yapıp.

    layout dosyasında bunu @viewbag.isim şeklinde yerleştirmekten ibaret.

    bu layout dosyasınıda sublayout dosyalarına bölebiliriz. yani .cshtml formatında header, footer, layout şeklinde 3 dosya oluşturup bunları ana layout dosyasında birleştirebiliriz. bu sayede html sayfasının da karmaşıklığının önüne geçmiş oluruz. bu parçalama işlemide şöyle oluyor;

    mesela footer kısmını parçalıcaz diyelim.
    _footer.cshtml dosyası oluşturduk, içerisine çeşitli html elementlerini yerleştirdik. kaydettik.
    ana layout dosyamız _layout.cshtml olsun, bu dosya içerisine footerın geleceği yere @html.partial("_footer") tagını ekliyoruz ve bu kadar.

    artık içerisinde @html.partial olan layout.css dosyamızı çağırdığımızda tüm kodlar geliyor. yani başka bir şey yapmaya gerek yok.
hesabın var mı? giriş yap