.Net Code Mimarisi Hk.
-
selam beyler - bayanlar,
Konu başlığı açıklayıcı olmadı lakin kafama takılan birşey var. Ufak bir iş için mvc projede excel upload içeriğini okuma kullanıcıya gösterme düzenleme vs vs operasyonlar yapılması isteniyor. Bunun için nette link teki gibi birşeyler buldum. Lakin bunu modüllere bölüp upload ayrı metod, exceli okuma için ayrı metod, gerekiyorsa silmeyi ayrı metod yapmak istesem nasıl bir yol izlemem lazım. Sonuçta tüm metodlar benden fileExtension ı bekleyecek, file ı bekleyecek vs vs.. Crud işleri olsa bi şekilde hazır yapılar var her türlü repository sini vs sini yazıyorsun da böyle operasyonel bir yapı nasıl kurulmalı sizce?
Bu mantığı kurabilmek için best practice anlamında takip ettiğiniz kaynaklar var mıdır?
-
boyle kucuk seyler icin ugrasmaya degmez hocam hepsini farkli fonksiyonlarda yaz gec,
ama profesyonel uygulamalarda nasil olur diyorsan Inversion of Control (IOC), dependency injenction (DI) kavramlarina bak, microsoft unity container, ninject, mef gibi teknolojileri ogren ve herseyini bagimsiz hale getir, enum bile kullanmazsin parametre islerinde :) ileri seviye konular bunlar
-
Hocam merhaba,
Sorunu tam anlayamamış olabilirim önceklikle.
Ben kendim bu tür işlemleri uygulamada Core Katmanı altında Utilities altında topluyorum. Utilities altında ise Extension Methods veya Excel gibi işlemlerimi topladığım sınıf,metod vb nesnelerim bulunmakta.
-
Eyv beyler,
@unbalanced hocam aynen dediğin gibi büyük projelerimizde bu yapıları kullanıyoruz. Tüm insert update delete ler daha doğrusu sql cümleciklerini kendi oluşturan yapılarımız var.
@intialcatalog hocam dediğin gibi bir şeyler yapayım bende :)
-
rappermcs bunu yazdı
Eyv beyler,
@unbalanced hocam aynen dediğin gibi büyük projelerimizde bu yapıları kullanıyoruz. Tüm insert update delete ler daha doğrusu sql cümleciklerini kendi oluşturan yapılarımız var.
@intialcatalog hocam dediğin gibi bir şeyler yapayım bende :)
hocam benim kast ettigim seyler crud islemler icin kullanilmaz daha dogrusu amac o degildir.
Soyle bir ornek vereyim, atiyorum 5 tane farkli class in var, bunlarin hepsini bir kutuya at ve baska bir class da bu class lari kullandiginda tumune ilk degerleri vermis ol hic parametre vermeden.. Anlatmasi biraz karisik ama cok farkli sekillerde kullanilabilir seyler bunlar. Bunla ilgili videolar falan izlersen ne demek istedigimi anlayabilirsin.
-
@unbalanced hocam konuyla alakalı paylaşabileceğin video vs var mıdır?
-
Dependency Injection, Inversion of Control yazilimda bagimliliklari azaltmak, daha esnek bir altyapi oluturabilmek icin vardir.
Surda epey guzel anlatiyo:
http://www.ilkayilknur.com/dependency-injection-nedir/
Genel olaraj SOLID prensiplerini de asagidaki videolar basarili bir sekilde anlatiyor, ornek uzerinden.
SOLID Kavramlari:
Creating SOLID Code: Single Responsibility Principle (SRP): http://dimecasts.net/Casts/
CastDetails/88 Creating SOLID Code: Open/Closed Principle (OCP): http://dimecasts.net/Casts/CastDetails/90 Creating SOLID Code: Liskov Substitution Principle: http://dimecasts.net/Casts/CastDetails/92 Creating SOLID Code: Interface Segregation Principle: http://dimecasts.net/Casts/CastDetails/94 Creating SOLID Code: Dependency Inversion Principle: http://dimecasts.net/Casts/CastDetails/96 -
Hocam sorunu tam doğru anlayamamış olabilirim ancak, desing patterns'a bakmak sana kodunu nasıl böleceğini nasıl yöneteceğini konusunda fikir ve yol gösterebilir. Mesela excel connectionunu oluşturmak için Factory Pattern kullanabilirsin. Update/delete gibi işlemler için CommanPattern gibi... @unbalanced 'in dediği gibi Container'larla projenin bağımlılıklarını ortadan kaldırabilirsin (azaltabilirsin).
-
TeRRoR bunu yazdı
Hocam sorunu tam doğru anlayamamış olabilirim ancak, desing patterns'a bakmak sana kodunu nasıl böleceğini nasıl yöneteceğini konusunda fikir ve yol gösterebilir. Mesela excel connectionunu oluşturmak için Factory Pattern kullanabilirsin. Update/delete gibi işlemler için CommanPattern gibi... @unbalanced 'in dediği gibi Container'larla projenin bağımlılıklarını ortadan kaldırabilirsin (azaltabilirsin).
Aynen hocam bu sabah biraz giriş yapmıştım. Senin yorumunu görünce de doğru bir yolda olduğumu farketim. @unbalanced hocanın dediği gibi bağımlılıkları azaltmak için yapılacak bi kaç bişey daha var aslında.
Core.Facade.ExcelFacade.Yap(file); diyerek her metodda ortak kullanılan fileExtension, fileName, ExcelConnectionString gibi tipleri ortak bir çatı altında topladım.
-
rappermcs bunu yazdıTeRRoR bunu yazdı
Hocam sorunu tam doğru anlayamamış olabilirim ancak, desing patterns'a bakmak sana kodunu nasıl böleceğini nasıl yöneteceğini konusunda fikir ve yol gösterebilir. Mesela excel connectionunu oluşturmak için Factory Pattern kullanabilirsin. Update/delete gibi işlemler için CommanPattern gibi... @unbalanced 'in dediği gibi Container'larla projenin bağımlılıklarını ortadan kaldırabilirsin (azaltabilirsin).
Aynen hocam bu sabah biraz giriş yapmıştım. Senin yorumunu görünce de doğru bir yolda olduğumu farketim. @unbalanced hocanın dediği gibi bağımlılıkları azaltmak için yapılacak bi kaç bişey daha var aslında.
Core.Facade.ExcelFacade.Yap(file); diyerek her metodda ortak kullanılan fileExtension, fileName, ExcelConnectionString gibi tipleri ortak bir çatı altında topladım.
Mesela hocam 2 şekilde ele alabiliriz class'ları. 1 Connector, 2 Operation. Bu iki class'ın interfacelerini oluşturup. Bu Interface'den türettiğin Excel11Connector Excel11Operaration, Excel12Connector Excel12Operaration ve Dependency Injection ile uygulamanda kullanacağın Excel versionunu göre Inject edersen uygulamandaki hiçbir kod değişmeden sadece Dependency Injection esnasında Inject ettiğin Connector ve Operaration class ları uygulamanı daha esnek bir hale getirebilirsin. Aynı zamanda özel Excel sınıflarından Abstraction sağlamış olursun. Head First Design Patterns kitabına bakarsan ve mantığını anlarsan yukarda bahsettiğim şeyleri çok rahat sindirebilirsin. Ama unutmamak gereken birşey var direk olarak Pattern'ı implemente etmek bazen zor olabiliyor (deneyimle kolaylaşacağını düşünüyorum). Code refactoring ile ve ReSharper benzeri tool'larla ilk başta yazdığın kodu adam edip uygun olan Pattern'a dönüştürebilirsin.
-
TeRRoR bunu yazdırappermcs bunu yazdıTeRRoR bunu yazdı
Hocam sorunu tam doğru anlayamamış olabilirim ancak, desing patterns'a bakmak sana kodunu nasıl böleceğini nasıl yöneteceğini konusunda fikir ve yol gösterebilir. Mesela excel connectionunu oluşturmak için Factory Pattern kullanabilirsin. Update/delete gibi işlemler için CommanPattern gibi... @unbalanced 'in dediği gibi Container'larla projenin bağımlılıklarını ortadan kaldırabilirsin (azaltabilirsin).
Aynen hocam bu sabah biraz giriş yapmıştım. Senin yorumunu görünce de doğru bir yolda olduğumu farketim. @unbalanced hocanın dediği gibi bağımlılıkları azaltmak için yapılacak bi kaç bişey daha var aslında.
Core.Facade.ExcelFacade.Yap(file); diyerek her metodda ortak kullanılan fileExtension, fileName, ExcelConnectionString gibi tipleri ortak bir çatı altında topladım.
Mesela hocam 2 şekilde ele alabiliriz class'ları. 1 Connector, 2 Operation. Bu iki class'ın interfacelerini oluşturup. Bu Interface'den türettiğin Excel11Connector Excel11Operaration, Excel12Connector Excel12Operaration ve Dependency Injection ile uygulamanda kullanacağın Excel versionunu göre Inject edersen uygulamandaki hiçbir kod değişmeden sadece Dependency Injection esnasında Inject ettiğin Connector ve Operaration class ları uygulamanı daha esnek bir hale getirebilirsin. Aynı zamanda özel Excel sınıflarından Abstraction sağlamış olursun. Head First Design Patterns kitabına bakarsan ve mantığını anlarsan yukarda bahsettiğim şeyleri çok rahat sindirebilirsin. Ama unutmamak gereken birşey var direk olarak Pattern'ı implemente etmek bazen zor olabiliyor (deneyimle kolaylaşacağını düşünüyorum). Code refactoring ile ve ReSharper benzeri tool'larla ilk başta yazdığın kodu adam edip uygun olan Pattern'a dönüştürebilirsin.
@TeRRoR hocam bilgilendirme çok açıklayıcı oldu emeğine sağlık. kitaba bakacağım.
edit: şuraya bırakayım lazım olan faydalansın :)
http://www.sws.bfh.ch/~amrhein/ADP/HeadFirstDesignPatterns.pdf