Introduction- MVC - Githubissues

MVC harfleri Model ‑ View (Görünüm)‑ Controller (Derleyici) anlamına gelir.
MVC deseni, epey yıldır var olan mimari bir modeldir.
Bu, ASP.NET'e özgü değil, ondan çok uzak.
Kod veya sınıfların yalnızca bir şeyi ve tek bir şeyi yapması gerektiği akılda tutularak oluşturulmuştur.
Başka bir deyişle, endişelerin ayrılmasını iyileştirmek için.
Bu, daha gevşek bağlı sistemlerle sonuçlanır ve net sonuç, çok daha test edilebilir ve bakımı yapılabilir bir yazılım elde edeceğimizdir.
MVC'de tipik olarak üç yapı taşımız olacak.
Model, kullanıcının birlikte çalıştığı verileri içerir.
Bunlar, genellikle model mantığı veya alan mantığı olarak adlandırılan, alan sınıfları ve bu verilerle çalışacak işlemlerdir.
Tipik olarak, buradaki sınıflar, üzerinde çalışacağımız modeldeki her şeyi temsil eder.
Bethany's Pie Shop söz konusu olduğunda, bir Pie sınıfımız, bir Sipariş sınıfımız vb. olacak.
Controller, üzerinde çalışan mantığı sağlayacaktır.
veri modeli ve görünümün görüntülemesi için veri sağlar.
Son olarak View lar, verileri başka bir controller action tarafından yeniden işlenebilmesi için kullanıcıya göstermek için mantık içerecektir.
ASP.NET Core MVC'de alacağımız akışa baktığımızda, controller sınıflarından birine bir istek geleceğini göreceğiz.
Controller lar, bir URL ile ilişkilendirilen genel yöntemler olan eylem yöntemlerine sahiptir.
Dolayısıyla, kullanıcı belirli bir URL'ye göz attığında, belirli yöntem o controller ı çağrılacaktır.
Bu da model üzerindeki kodu tetikleyecek ve ardından modelden kullanıcıya veriyle görüntülenecek bir görünüm seçilecektir.
ASP.NET Core MVC'deki view lar, görünüm motoru olan Razor'u kullanıyor.
ASP.NET Core ile ASP.NET Core MVC arasında bir fark olduğunu anlamak önemlidir.
ASP.NET Core temeldir.
Açık kaynak çerçevesidir ve modern web uygulamaları oluşturmamızı sağlar.

ASP.NET Core MVC temelde yukarıdaki bir katmandır ve tabloya web API'leri ve web uygulamaları oluşturma becerisini getirir.
MVC'nin yanında, Razor Pages çerçevesi veya Blazor gibi diğer çerçeveler ASP.NET Core'a eklenir.

ASP.NET Core MVC'nin oldukça geleneksel temelli olduğunu anlamak önemlidir.
Bu, varsayılan olarak, belirli bileşenlerin belirli bir klasörde olmasını veya belirli bir ada sahip olmasını bekleyeceği anlamına gelir.
Varsayılan olarak, ASP.NET Core uygulamaları yapı taşlarının her biri için ortak klasörler kullanır, bu nedenle genellikle bir MVC uygulamasında bir Controllers, Models ve Views klasörü göreceğiz.
İlkine, Modellere bakalım.
Şimdi modele zaten birkaç kez atıfta bulunuyoruz, ama o zaman bu model tam olarak nedir?
Modeli, etki alanı verilerini oluşturan sınıflar grubu olarak adlandırıyoruz, bu nedenle bunlar tipik olarak düz eski CLR sınıfları veya POCO sınıflarıdır.
Model, etki alanı verilerinin yanında, verileri yöneten sınıfları da içerir.
İkincisi daha sonra tipik olarak bir depo(repository ) sınıfı olacaktır, ancak bunun üzerine bir saniye içinde daha fazlası olacaktır.
Model tipik olarak basit bir API'ye sahip olmalıdır ve
ana amacı, tüketiciden gelen gerçek verileri nasıl yönettiğimize veya onlarla nasıl etkileşime girdiğimize dair nitty ayrıntılarını gizlemektir.
Gerçek veri etkileşimini gerçekleştiren kodu kod tabanımıza yaymak istemiyoruz.
Bu kodu modelin içinde gruplamak istiyoruz.
Ayrıca gerçek veri kalıcılığını gerçekleştirecek sınıflara da ihtiyacımız olacak.
Bu, kalıcılığın nasıl gerçekleştiğinin ayrıntılarını özetleyen bir sınıf olan bir depo sınıfı oluşturarak ele alınacaktır.
Gerçekten çevrildiyse, uygulama kodumuzu nesnelerde kalıcı olan kodla doldurmak istemiyoruz.

Konteynere öğeleri kaydederken, bunu yapmak için bir dizi seçeneğimiz vardır ve bunlar,
nesnelerin yaratılma şekli ve ne kadar süreyle yaşayacakları bakımından farklılık gösterir.
AddTransient'i kullandığımızda, kapsayıcıdan bir örnek istediğimizde, yeni bir temiz örnek alacağız.
AddSingleton yöntemi, temelde tek bir nesne olan tek bir nesnenin oluşturulmasına neden olur.
Her örnek istediğimizde, aynı örneği geri alacağız.
AddScoped, Kapsamlı ömür boyu hizmetler istek başına bir kez oluşturulur.
Temel olarak, MVC, HTTP isteği başına bir örnek oluşturur, ancak aynı örneği aynı web isteği içindeki diğer çağrılarda kullanır.

Controller

MVC hikayesinin tamamında, controller ın çok merkezi ve önemli bir rolü vardır.
Controller ı bir MVC uygulamasında yönetici veya trafik temsilcisi olarak görebiliriz.
Sonunda müşteriye geri gönderilecek yanıtı oluşturmak için model i ve view ı kullanacaktır.
Controller, bu nedenle kullanıcı etkileşimine yanıt vermekten sorumlu olacaktır.
Örneğin, kullanıcı bir düğmeye tıkladığında ve istek sunucuya gönderildiğinde,
bu istek bir controller tarafından alınacaktır.
Bu nedenle, kullanıcı etkileşimine dayalı bir yanıt oluşturma sorumluluğu controller a aittir.
Bunu yaparken, controller, modelle doğrudan etkileşime girecek olan taraftır.
kullanıcı etkileşimine yanıt olarak modeli güncelleyecek olan controller dır.
Bunun için modeli kullanarak, controller ın gerçek veri kalıcılığının nasıl çalıştığını bilmesine gerek kalmaz.
bu ayrıntıları controller dan gizlemek modelin görevi.
bir controller bir cümleden başka bir şey değildir ve Controller adlı bir temel sınıftan miras alır.
MVC'de, bir controller ın adı genellikle Controller ile sonlandırılır.
Bu, çerçevede (framework) bir kuraldır.
Gelen bir talebe cevap verenin controller dır
Doğrusu, bu aslında bir talep (request) alındığında controller da çağrılacak bir metottur.
Böyle bir metot, bir action veya action metodudur.
Örneğin kodda, bu İndeks yöntemi olacaktır.
Bu yöntem daha sonra çalıştırılır ve genellikle MVC durumunda, sonuç olarak sonunda bir view (görünüm) döndürür.
Bu nedenle, dönüş türü de bir View sonucudur.
Bu, daha sonra kullanıcının bir istek göndermesinin sonucu olarak bir web sayfasını görmesini sağlayacaktır.
Hangi görünümün gösterileceğini belirlemek için ASP.NET Core MVC bir kuralı izler.
Elbette, gerçek bir eylem meta veri controller ı , genellikle bir view ı döndürmekten daha fazlasını yapacaktır.

Yukarıdaki resimde controller, yapıcı enjeksiyonu (constructor injection) aracılığıyla aldığı pieRepository'den yararlanıyor.
Aslında, bununla ilgilenen yerleşik ASP.NET Core MVC bağımlılık enjeksiyon sistemidir.
Controller a otomatik olarak bir örnek enjekte edilecektir.

View

Controller da harika kodlar yazabiliriz, ancak görselleştirecek hiçbir şey olmadığı sürece, kullanıcı kodumuzun hiçbirini kullanamayacak, Öyleyse view tam olarak nedir? Vİew aslında bir şablon, bir HTML şablonu olarak görülür

Modelden verileri görselleştirmek için kullanılacak biçimlendirme kodunu içerir.
Veriler, örneğin bir turta listesi ise, bu durumda görünümümüz (view),
listedeki tüm pastalar üzerinde döngü oluşturacak ve her birini, örneğin bir tablodaki bir satırda görselleştirecek bir kod içerebilir.
ASP.NET Core MVC'de, view şablonları cshtml dosyalarıdır.
Bunlar, biçimlendirme kodunu içerecek dosyalardır.
ASP.NET Core MVC bağlamında (context), iki tür görünümü ayırt edebiliriz,
düz veya normal görünüm (Plain) veya kesin olarak yazılmış bir görünüm (strongly-typed ).
çoğu zaman ASP.NET Core MVC olması durumunda güçlü yazılmış görünümler (strongly-typed ) kullanırız
View larda, oluşturduğumuz web sayfalarında C # kodunu kullanmamızı sağlayan bir işaretleme sözdizimi olan Razor'dan da yararlanacağız.
Ama önce ilk şeyler.
View larımız, belirtildiği gibi, cshtml dosyalarıdır.
- Kural olarak, view lar , uygulamanın kökünün altındaki bir klasör olan Views klasörüne yerleştirilir.
- Orada, Controllers klasöründe sahip olduğumuz her controller için ilgili bir alt klasör oluşturulacaktır.
- Dolayısıyla, bir PieController'ımız varsa, Views klasörünün altında bir de Pie alt klasörümüz olur.

Bu klasörde, her view bir cshtml dosyasıyla temsil edilir.
Yani her controller için, tüm cshtml dosyalarının bulunduğu bir alt klasöre ihtiyacımız var,
ancak controller o zaman hangi view ın işlenmesi gerektiğini nasıl bilecek?
Indeks metoduna sahip olduğumuz ve View ı döndürdüğümüz yerde örnek controller ı düşünelim.
Yine, kural olarak, gösterilecek view a Index.cshtml adı verilir,
bu nedenle eylem yöntemiyle aynı addır.
Bu view bulunamazsa, bir istisna atılır.
Burada da statik bir HTML sayfası kullanabilirdik.
- Bu teknik olarak bir view olsa da, pek dinamik değil
- Tabii ki, view lar çok daha fazlasını yapabilir.
- Verileri view a aktarmamız gerekecek.
- Verileri aktarmanın birkaç yolu vardır.
- Muhtemelen en basit olanı ViewBag adlı bir şey kullanmaktır.
- ViewBag, controller dan veri ekleyebileceğimiz dinamik bir nesnedir.
- ViewBag dinamik olduğu için, istediğim kadar özellik ekleyebilir ve onlara istediğim adı verebilirim.
- View ımız artık bu verilere de erişebilir ve bu şekilde gerçekten biraz daha dinamik, dinamik bir görünüm haline gelebilir.
- Burada görebileceğimiz gibi, Mesaj özelliğine veri ekliyorum.
- Ve ViewBag dinamik olduğu için, istediğim kadar özellik ekleyebilir ve onlara istediğim adı verebilirim.

Neredeyse saf HTML olan çok basit bir görünüm görüyoruz, ancak vurgulanan çizgiye tekrar dikkat edelim.
Kodda satırın başında @ sembolü bulunur ve bu temelde Razor sözdizimidir.
Bu satırın aslında değerlendirilmesi gereken kodu içerdiğini belirten bir işarettir.
@ sembolünden sonra tekrar ViewBag.Message'ı görüyoruz.
Ve burada olan şey şu ki, view kodum artık controller la aynı ViewBag nesnesine erişiyor ve artık controller kodunda belirtilen özellikleri okuyabiliyor.
Bu şekilde, controller ve view veri alışverişi yapabilir.
Şimdi, önemli bir sorun, buradaki dinamik yöndür.
Gerçek uygulamalarda, tüm geçmiş veriler temel nesne türünde olduğu için oldukça fazla döküm yapmamız gerekecek.
Açıkça belirtmek gerekirse, işaretleme kodumuz, yani view kodumuz, Razor sözdizimi kullanılarak yazılacaktır.
Razor, web sayfalarımızın içine C # kodunu eklememizi sağlayan bir işaretleme sözdizimidir.
Kod elbette sunucu tarafında yürütülür,
bu nedenle kodu çalıştıran ASP.NET Core olacaktır ve ortaya çıkan HTML istemcilere gönderilecektir.
ViewBag'in dinamik olması nedeniyle, hepsini o kadar sık kullanmayacağız
ve bunun yerine oluşturacağımız görünümlerin çoğu, sözde güçlü tiplenmiş görünümler (strongly-typed views) olacaktır.
Burada gördüğünüz kodda, List adlı bir eylem yöntemim var ve bu sadece bir view döndürmüyor.
Bunun yerine, parametre olarak repository olan .Pies'i kullanarak bir pie listesi göndererek bir view döndürüyor.
Bu, bu listenin artık perde arkasında döndürülen view sonucunun ViewData.Model özelliği olarak ayarlanmasına neden olur.
Net sonuç, view ın bu listeye erişmesidir.

Şu anda üzerinde çalıştığımız şey, güçlü bir şekilde yazılmış (strongly-typed) bir view dır.
Kesin olarak yazılmış bir view (strongly-typed view) oluşturmak için,
en üstte aktarılacak nesnenin türünü eklememiz gerekir.
Burada yapılan şey yine,
modeldeki tüm pie ların üzerinde döngü yapmak için Razor kodunu kullanmak,
böylece model, controller kodunda view a aktardığımız listeydi.
Burada bir foreach Razor ifadesi kullanıldı ve bu sadece bir C # ifadesidir.
Döngünün içinde, daha fazla HTML öğesi oluşturuldu.
Ve yine, Razor ifadeleri aracılığıyla, artık her bir pie ın adı ve fiyatı gibi listedeki her bir öğenin özelliklerine erişebiliyoruz.
Çoğu durumda, view a aktarmak istediğimiz modelin bir alan modeliyle eşleşmediğini göreceğiz.
Örneğin, görünümümüzün turta listesini göstermesi gerekir,
ancak turtaların ait olduğu kategorinin adını da göstermesi gerekir.
Bu durumda ViewBag'i tekrar kullanabiliriz ve ekstra verileri, yani ViewBag'i kullanarak kategorinin adını iletebiliriz.
Şimdi bu işe yararken, daha iyi bir yaklaşım,
görünüm modeli (view model) adı verilen bir şey kullanmaktır.
Görünüm modeli (View Model), view ihtiyaç duyduğu tüm verilere erişebilmesi için birden çok özelliği saran bir sınıftır.
Böyle bir görüş modeli, tam anlamıyla görünüm için bir model olarak görülebilir.
Parçacıkta burada görebileceğimiz, kodda kullanılacak bu view modeli sınıflarından biri olan PiesListViewModel'a bakalım.
Sınıf, etki alanı modeli gibi bir IEnumerable içinde Pies sarmalar,
ancak aynı zamanda CurrentCategory özelliğiyle birlikte gelir.
Bu görünüm modelinin bir örneği, böylelikle türü güçlü bir şekilde belirlenmiş görünümümüze aktarılacaktır.

Uygulama geliştirirken göz önünde tutmamız gereken noktalardan biri de uygulama içerisindeki kavramların birbirinden ayrık biçimde çalışacak biçimde geliştirilmesi(Seperation of concerns).
Bu şekilde bir uygulama geliştirme mantığı benimsediğimizde uygulamamız içerisinde bulunan yapılar birbiri ile sıkı sıkıya bağlı olmayacak ve böylece birinde yapılacak olan değişiklikler diğer yapıları olabildiğince az etkileyecek.
Web tarafına kavramların birbirinden ayrılmasını sağlayan bir pattern (Model-View-Controller(MVC)) bulunmaktadır .

MVVM (Model-View-ViewModel )

MVVM patternının temeline indiğimizde ise Martin Fowler'ın önermiş olduğu Presentation Model'i görmekteyiz. Aslında MVVM, Presentation Model mimarisinin WPF ve Silverlight teknolojileri için özelleştirilmiş bir halidir. Doğrudan Silverlight ve WPF için özelleştirilmiş bir uygulama geliştirme mimarisi olduğu içinde haliyle bu teknolojilerin tüm özelllikleri fazlasıyla bu mimari model içerisinde kullanılmakta.

MVVM yapısının temel parçaları.
Model : Model, uygulama içerisinde kullanacağımız olan datadır. Bu datalar WCF RIA Services ile döndürülen entityler olabileceği gibi doğrudan tanımlanmış POCO nesneleri de olabilir.
View : View, datanın sunulduğu katmandır. Tüm görsellikler View'da yer alır. Kısaca verinin sunulduğu yerdir(Ekran).
ViewModel : ViewModel ise Model ile View'ı bağlayan yapıdır. View ile Model arasında bir yapıştırıcı görevi görür. View doğrudan ViewModel yardımıyla Model'e erişir ve bazı işlemleri gerçekleştirir. Teknolojik olarak WPF veya Silverlight teknolojilerinden konuşursak ViewModel aslında View'ın DataContext'idir.
MVVM yapısına baktığımız zaman WPF ve Silverlight teknolojilerinde bulunan Commanding, Binding, Behaviour gibi özellikleri sıklıkla kullanılır.

MVVM'in getirdiği artılar

Commanding, Binding, Behaviour gibi özellikleri kullanarak dekleratif programlama özelliklerini kullanarak hızlı ve etkin uygulama geliştirme.
View arkasında bulunan kod dosyası içerisinde sıfır kod yazarak bağımlılıkları minimuma indirmek ve uygulama içerisinde katmanların bağımlılıklarını minimuma indirmek.
Daha genişletilebilir, bakımı yapılabilir ve test edilebilir uygulamalar geliştirmek.
Arayüzü kolay bir şekilde taşınabilen uygulamalar geliştirmek.

_Layout.cshtml

ASP.NET Core MVC, view larımızın başvurabileceği bir şablon olan bir düzen dosyasıyla birlikte gelir.
Genel işaretlemeyi içerecek ve diğer görünümler içeriklerini Layout (Düzen) şablonunun içine yerleştirebilir.
Böyle bir şablon tipik olarak Shared (Paylaşılan) klasöre yerleştirilecektir.
ASP.NET Core MVC, varsayılan olarak bu konuma bakacaktır.
Bu yine bir kural.
Bu uygulamada sadece bir tane olacak.
Ancak, gerçek hayattaki bir uygulamanın tipik olarak birden fazla Layout dosyasına sahip olunabilir;
örneğin, biri yönetici sayfaları ve biri genel sayfalar için.

Görselde bi Layout şablonu örneğini görebilirsiniz.
- Tam sayfa işaretlemeyi içerir ve ayrıca yine bir Razor ifadesi olan bir yer tutucu içerir.
- Burada view içeriğinin nereye yerleştirileceğini gösteren @RenderBody kullanıyoruz.

ViewStart

Şimdi bir sonraki görseldeki şey, view larımınzın kullanmak isteyecekleri layout u göstermesi gerekecek.
Bunu her view da doğrudan burada gördüğümüz kodu kullanarak yapabiliriz.
Ancak tipik olarak, ViewStart dosyası adı verilen bir şey kullanacağız.
Bir view işlendiğinde ASP.NET Core MVC tarafından otomatik olarak aranacak başka bir view dır.
ViewStart dosyasında, genellikle orada herhangi bir view çağrıldığında yürütmek istediğimiz bir kodu yerleştiririz ve ardından hangi yerleşim dosyasının kullanılması gerektiğini belirtiriz.
- Layout.cshtml'yi belirtmediğime dikkat edin, sadece _Layout kullanıyoruz.

View Imports

Bir tane daha özel dosya var ve bu dosya özellikle ASP.NET Core MVC ile eklenmiştir ve adı ViewImports dosyasıdır.

Adından da anlaşılacağı gibi, bu dosya bir @using ifadesiyle türleri dahil etmek için kullanılır.
Bu türler, view kodunu eklediğimizde otomatik olarak bilinecektir.

Bootstrap & Libman

çok popüler bir CSS kitaplığıdır
bir istemci tarafı paketidir (client-side)
Visual Studio da artık Kitaplık Yöneticisi (Library Manager) ile birlikte geliyor.
Kütüphane Yöneticisi'ni (Library Manager) veya kısaca LibMan'ı kullanarak, bir paket kaynağından istemci tarafı paketleri kolayca dahil edebiliriz.
Kütüphane Yöneticisinde yaptığımız her şey, projeye ilk kullanımda eklenen bir JSON dosyasına kaydedilecektir.
Varsayılan olarak, bu dosya oldukça boştur. Varsayılan dosya
Bağımlılıkları getirmek için bu dosyayı manuel olarak düzenleyebilir veya paketleri aramak ve projeye eklemek için Kitaplık Yöneticisi arayüzünü (Library Manager interface) kullanabiliriz.

!! Uyarı

Visual Studio 2017 kullanıyorsa, Microsoft yalnızca daha yeni güncellemelerde Kitaplık Yöneticisi'ni de bu sürüme (2019) tanıttı.
Visual Studio 2017'nin ömrü boyunca Microsoft, istemci tarafı paketleri ekleme şeklini birkaç kez değiştirdi.
- Başlangıçta Bower için destek aldık, ancak bu artık desteklenmiyor.
Hala Visual Studio 2017'nin daha eski, yakın zamanda güncellenmemiş bir sürümünü kullanıyorsa, paketleri manuel olarak eklemek en iyi seçenek olabilir.

KevserAkbas / BethanysPieShop

Introduction- MVC #4