Jump to content

Winterex

Moderators
  • Content Count

    11
  • Joined

  • Last visited

  • Days Won

    3

Winterex last won the day on July 10

Winterex had the most liked content!

Community Reputation

4 Neutral

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Merhaba Kürşat, Authentication'da hatırlıyorsan Response.Redirect ile kullanıcının yönlendirilecegi sayfayı seçiyorduk. Eğer tam bu esnada bir TempData tutarsan (OnAuthorizeCore metodunun icinde olusturup) veya Session'a bir mesaj eklersen eger kişi buraya düşmüşse ve istediğin şartlara girmişse o program o mesajı oluşturmuş olacak ve ulaşılan sayfadan da mesaj yakalanmaya müsait olacaktır
  2. Merhabalar. Bu durumda kurduğumuz normalizasyonda sizin bir Dersler tablonuzun olmasının yanı sıra bir de o derslere baglı olan DersBilgileri isimli bir tablo olarak bunların bire cok bir şekilde baglanması gerekir (Bir dersin n dersbilgisi vardır, bir dersbilgisi sadece 1 derse aittir(ona ozeldir)). Dolayısıyla bu one to many tablomuzda derslerimizin id'leri ile dersbilgilerimizin icerisindeki foreignkey olan DersId sütunumuz ilişki ile baglanacagından dolayı siz ilgili derse tıkladıgınızda bir EF linq sorgusu ile ilgili DersId'sini gönderip sadece o dersin bilgilerini getir derseniz ve acacagınız tek sayfada o bilgileri cagırmıs olursanız hem agile(cevik) bir şekilde tek sayfayla işinizi halletmiş olur ve her ders icin ayrı sayfa kalabalıgından kurtulursunuz hem de her derse tıkladıgınızda sadece ona özel bilgiler gelmiş olur.. Umarım yardımcı olabilmişimdir. İyi çalışmalar dilerim...
  3. Kürşat merhaba. Junction Table'a zaten eklemiş olduğun bir verinin composite key değerlerinin aynısı bir daha eklenmeye çalıştığı için Violation of Primary Key hatası alıyorsun. Bu durumda tam o sırada bir breakpoint atarak ekleyecegin composite key'lerin degerine ayrı ayrı bakar mısın. Eger bunlar daha önceki Composite Key'ler ile tutuyorsa bundan emin olursun. Durum böyleyse kurduğun normalizasyon hakkında bir konuşup onu düzenlememiz gerekecek. Veya bu senaryoya has olarak ilgili CompositeKey'den (cünkü kombinasyon özellikle isteniyor burada) key durumunu kaldırıp ayrı bir primary key acılabilir...
  4. Merhabalar, Böyle bir durumda önce ilgili class'ınızda bir Encapsulation prensibi ile birden fazla sütunu birleştirmeniz gerekiyor. DropDownList yapısı geregi sadece bir tek sütun degerini gösterebilir. Ancak eğer o sütun sizin istediginiz belli sütunları birleştiriyorsa amacınıza uygun olacaktır. Mesela Sql'e gitmeyen sadece get (read only) olan IsimSoyisim property'si acıp(tekrarlıyorum Ignore ile Sql'e gitmemesi gerekir cünkü Normalizasyon icin sıkıntılıdır) o property icinde Isim Soyismi birleştirip dropdownlist'te de EmployeeName yerine o property ismini yazmalısınız.
  5. Merhabalar, ID'leri sadece CoreEntity'den almakla iyi yapmışsınız o şu andaki sorunla ilgili olmasa da başka sorunlar çıkarırdı. Many To Many ilişkilerde eğer Class'lar arasındaki virtual property'ler dogru işlenmişse aslında Fluent API ile tekrar belirtmeden EF'ye bırakmak bunu daha saglıklı bir hale getirir(tıpkı .Net Framework'teki gibi Core platformu da bunu algılayacaktır). ManyToMany tablolarda HasKey metodundan sonra HasOne ile baslayan metotlar maalesef ilgili tekrar eden property ile ilgili bir işlem yapmayacaktır onları eski haline çevirebilirsiniz. Primary key tipleriniz Core'da Guid tipindeyse diger tüm Many to Many junction tablo olacak classlarda da Guid mi diye kontrol edebilir misiniz? Özellikle StudentSuccessDocument'da...Ayrıca DataAnnotations'ta Key ve Identity tanımlamasını silebilirsiniz. EF ID ismini gördügü anda onun primary key oldugunu anlayacak ve onu otomatik olarak identity yapacaktır. Bir de son iyileştirmeleri yaptığınızda migration'ı ve veritabanınız daha önce varsa veritabanınızı tamamen silip " add-migration initialcreate" kodunu package manager console'a yazarak bastan bir migration yaparsanız daha sağlıklı olacaktır. Son olarak dikkatimi çeken bir şey verilen hatada belirtilen tekrarlanan property (StudentID ve öncesindeki TeacherID'de) ID'lerdeki D büyük harfle yazılırken sizin property'lerinizde Id yani küçük d ile yazılmış. Burası cok önemli. Çünkü siz kücük harfle yazarken hatadaki property'nin büyük harfle verilmesi EF'nin bir eksiklik görüp Composite Key property'lerini kendisinin ek olarak yaratmaya çalıştığını belirtir ancak SQL incasesensitive olduğundan dolayı sizin diğer property'nizle cakısıp aynı property tekrarlıyor olrak görülüyor. Dolayısıyla hata şu şekilde kaynaklanıyor : Core'da tipi belli olan (GUID) bir ID'miz var. Ancak sonra baska sınıflarda ayrı bir şekilde key olarak bir baska ID int olarak belirtilmiş. En son nerede Key attribute'u verildiyse EF onu primary key olarak algılıyor. Sonra many to many icin junction (ara) tablo olacak sınıfımızda ise Composite Key'ler tekrar GUID olarak belirtiliyor ve isimleri StudentId , TeacherId vs. olarak veriliyor. İşte tam bu noktada EF'nin kafası karısıp "ya bunlar bazı yerlerde int bazı yerlerde Guid" gibi bir mantıkla ilişkisini aldıkları class primary key eger GUID yapılmadıysa int yapıldıysa kendisi otomatik bir şekilde apayrı int propertyler acarak bunlara kendi isimlendirmesiyle TeacherID ve StudentID veriyor ama bunlar da o ara tablonun class'ının icinde Guid olan TeacherId (kücük d'ye dikkat casing Sql'de yok) ve StudentId ile cakısıp aynı property olarak görülüyor ve ilgili hatayı cıkarıyor. Dolayısıyla tiplere dikkat eder ve aynı yerde standartları korursanız sorun cözülecektir. Yoğunluğumdan dolayı geç cevap verebildim. Sorun devam ederse lütfen tekrar iletişime geçin daha ayrıntılı bir anlatımla sorunu cözebiliriz.. Konuyu takibe alıyorum.
  6. Sevgili arkadaşlar bu yazımda sizlere tasarım desenleri (Design Patterns) nedir, neden kullanılır, neden mevcut yazılım geliştirme ortamlarında olmazsa olmazdır ve bu kadar büyük bir önem teşkil etmektedir onu anlatacağım... Temel olarak söylemek gerekirse tasarım desenleri, OOP prensiplerinin bir amaç için çözüm odaklı standartlaşmış kalıplarda kullanılmasıdır. Pek açıklayıcı olmadı değil mi? Bir de şöyle anlatayım... Hangi mekanda olursanız olun,hangi tarz projeyle uğraşırsanız uğraşın,hangi dili kullanırsanız kullanın, bir yazılımcı olarak sizlerin karşılaştığı problemler asla size özgü değildir. Tıpkı sizin gibi başka yazılımcılar da her ne kadar farklı dil kullansalar da,farklı projelerle uğraşsalar da kendi projelerinde sizinkine çok yakın ve özellikle bazı proje sistemlerinde tıpkı sizinkilerle birebir tutan aynı sorunlarla karşılaşmışlardır. Bu sorunlardan bahsederken tabii ki basit syntax(yazım kuralı) hatalarından veya çalışma zamanı (runtime exception)hatalarından bahsetmiyorum.Hatta mantıksal(logical) hatalardan bile bahsetmiyorum. Bahsettiğim sıkıntılar performans düşürücü, öngörülemeyen ihtimaller yüzünden projenin önünü kesici, proje normalde çalışmasına rağmen olur olmadık yerde bug çıkaran,projeye yeni bir şey eklenmek istediği zaman bunu mümkün kılmayan, esnekliği öldüren sorunlardır. İlgili yazılımcı artık klasik 3 kategoride belirlenen hataları çoktan aşmış, bir projeyi sonuna kadar getirmiş ve onu canlıya alıp başarıyla çalıştırmıştır. Ancak asıl olay burada başlar. Her şey bitmiş değildir. Çünkü çalışmakta olan projenin kalitesi ve yaşam süresi onun nasıl çalıştığına bağlıdır. Yazılımcının tek görevi çalışan bir uygulama yazmak değildir. Performanslı çalışan ve esnek -yani yeniliklere açık ve yeni gelecek ekip arkadaşları için geliştirici dostu bir uygulama yazmaktır. Dolayısıyla böyle bir uğraş içerisindeyken biz yazılımcıların karşılaştığı sorunlar ciddi ölçüde yavaşlatıcı ve bezdirici olabilir. Elbette bu tarz sorunlarla karşılaşan yazılımcılar kendi algoritmalarını kurup belirli sistemlerle bu sıkıntılardan kaçınabilirler. Ancak bu genelde standartlaşmış bir çözüm olmaktan ziyade spesifik ve sadece o anı kurtaran bir çözüm olur. Ayrıca kendi senaryosu için iyi olabilen bir çözüm bulmuşken başka senaryolarda çok önemli başka sıkıntılar meydana çıkma ihtimali de büyüktür. Yani bir kalıba uymaz.. İşte tasarım kalıpları bu tarz sorunlara karşı standartlaşmış ve sorunu tamamen çözen,problemi çözerken de başka bir sorun ortaya çıkarmayan,OOP prensiplerini kullanan algoritmalardır. Tasarım patternleri hayatımıza -daha doğrusu yazılım hayatına- Kent Beck ve Ward Cunningham önclüğünden sonra kendilerine Gang of Four diyen 4 yazılım bilimcisi(Erich Gamma,Richard Helm,Ralph Johnson,John Vissides) tarafından getirilerek proje geliştirme esnasında karşılaşılan senaryolara uygun kategorilere ayrılmıştır. Bu yazılım bilimcileri yazdıkları "Design Patterns: Elements of Reusable Object-Oriented Software" isimli kitaplarında Christopher Alexander'in ilk kez ortaya attığı önemli bu kavramı yazılıma entegre edip bir devrim yaratmışlardır. Gang of Four'a göre tasarım patternleri ortak yazılım problemlerine kalıcı çözümler sunar. OOP- yani Nesne Yönelimli Programlamada ise tasarım patternleri büyük ölçekli yazılım mimarileriyle ilgilenmekten ziyade nesnelerin birbirleriyle davranışları ve ilişkileri ile ilgili sorunları çözmekle ilgilenir(zaten bu yüzdendir ki mimari paternler ile tasarım paternleri arasında fark vardır.). Yani bir tasarım paterni kullanıyorsanız sizin projenizin mimarisi zaten bellidir ve sağlamdır. Siz sadece bu mimari içindeki çalışma mantığında güzel ve sorunsuz bir iş akışı için bu paterni kullanırsınız. Onların olmaması projenizin çalışmayacağı anlamına gelmez. Ancak projenizin profesyonel bir yapıdan ziyade sorun çıkarmaya yatkın ve değişime sıcak bakmayan bir yapı olduğunu gösterir. Tasarım desenleri kategorisel olarak üçe ayrılır: Creational (Oluşturucu), Structural(Yapısal), Behavioral (Davranışsal) paternler. Bu kalıpların her birinin özel ilgilendiği senaryolar ve içlerinde barındırdığı paternler var. Sonraki yazılarımda Creational Pattern'i açıklayıp GoF'un belirttiği senaryoları açıklayacağım. Biliyorum belki de size çok fazla tarihsel ve teorik bilgi sundum. Ancak tasarım paternlerinin algoritmasını öğrenmeye başlamadan önce onların ne olduğunun ve neden yazılım hayatına girdiğinin anlaşılması bence önemli. Ben zaten her kategoride her paternle ilgili ayrı yazılarımda bir anlatım ve kod örnekleri yazacağım. Fakat bunlardan önce bence bir yazılımcının kullandığı her şeyin nedenini anlaması en az kullandığı kalıplar kadar önemlidir. Sonraki yazımda görüşmek üzere...Hoşçakalın.
  7. Merhabalar, ManyToMany ilişkisinde kullandıgınız sınıfların kodlarını göndermeniz mümkün müdür? O şekilde daha yardımcı olabiliriz. Yine de hataya baktığımda büyük ihtimalle bir tabloda (coka cok ilişkiyi kurdugunuz sınıfların dönüstügü tablolarda) bir sütunun isminin tekrarlandığı durumu belirtilmiş. Belki de Teacher veya Syllabus sınıflarınıza verdiginiz miraslar sayesinde bu class'lardan bir tanesine bir hidden property gidiyor ve ilgili class EF tarafından tabloya dönüstürülürken aynı isimde iki property alıyor(hem miras aldıgı hidden property hem de kendisinin explicit property'si). Dolayısıyla bir tabloda sütun isimleri 'özgün' olması gerektiginden dolayı böyle bir hatayla karsılasıyorsunuz. Yine de dedigim gibi class kodlarınıza bakarsak daha kesin bir cözüm iletebiliriz.
  8. Merhabalar çok geç fark ettim yazdığınızı. Eğer N-Tier mimari modeli kullanıyorsanız DAL katmanında bulunan Context sınıfınızda override ile ezdiginiz OnModelCreating metodunun icine ilgili sorunu coka cok ilişkide yasadıgınızdan dolayı modelBuilder.Conventions.Remove<ManyToManyCascadeDeleteConvention>(); kod örneğini entegre etmeniz OrderDetails tablosunda eğer bir düzenleme yapılacaksa burada hata alma durumunu ortadan kaldıracaktır. Tabii ki bu cascade convention'i tamamen silme durumlarında işe yarar. Ancak sanırım sizin algoritmanızda Admin onay vermeden OrderDetails tablosuna ekleme yapılmıyor. Yani aslında veriler önceden hazırlanıyor ancak ne zaman ki Admin onay verir o zaman yükleniyor veya baska bir ihtimal OrderDetails verileri ilk basta "Onay bekleyen" statüsünde geliyor ondan sonra onay verilmiş olarak degişiyor. Böyle bir durumda bir OrderDetails verisini composite key kümesinin tek bir key'inden yakalamak mümkün degildir cünkü Composite Key aslında ayrılamayan bir bütündür. Sizin karar mekanizmanızda kacınılmaz bir şekilde önceden olusturulmus veri Find metodu ile tekrar bulunup bizzat bir composite key üzerinden degiştirilmeye calısıyor. Bu gibi durumlarda modifiye etmeyi gercekten istiyorsanız many to many tablosunda composite key degiştirmek mümkün olmadıgından dolayı (ProductID hatası o yüzden cıkıyor resimde) kaldırıp tekrar belirli kurallara göre eklemek en iyi cözümdür. Maalesef projenizi bilmedigim icin sadece Cascade kodunu gönderebildim. Asıl cözüm yolu algoritmayı composite key'i degiştirmeden Edit yönteminden gecmektedir. Umarım acıklayıcı olabilmişimdir. İsterseniz dedigim gibi projenin hata veren halini de yollayabilirsiniz. En kısa zamanda geri dönüş yapabiliriz
  9. Merhabalar. İlgili View'a Model'i action'dan göndermemişsiniz. Tekrar kontrol eder misiniz? (Action tarafında return View() kısmında View parantezleri icerisine model koymanız gerekir)
  10. Merhabalar. Çoka çok olması gereken bir tabloyu değiştirerek kendine has bir ID kolonu koymak aslında onun yapısını bozmak olduğundan dolayı aslında bu Normalizasyon açısından tercih edilmeyen bir çözümdür. Varsayılan görünümde iş akışı hata vermiyormuş gibi gözükebilir ancak siparişlerin ve satışların raporlanmasında SQL'de ciddi anlamda sorun çıkaracaktır ve yanlış raporlar oluşturacaktır. Aldığnız hatanın nedeni Composite Key olan kümedeki bir yapıyı değiştirmek istediginizde Entity Framework'un bu sorguyu SQL'e göndermeyi mümkün olarak görmeyip 'ben bunu modifiye edemem Normalizasyonda bu seçenek bana veya SQL'e sunulmamış' demektir. Çözümü ise Fluent API'de composite key'e oncascade özelliği vermek veya başka bir algoritmayla Composite Key kümesini yakalayarak o kümeden herhangi bir yapıyı modifiye etmeden sipariş detaylarını düzenlemektir. Eğer son söylediklerim biraz karışık geldiyse veya çok havada kaldıysa isterseniz kod örneği gönderebilirim . Veya Projenizi (Sanırım Fatih Hoca'yla yapıyorsanız o da gönderebilir) gönderirseniz uygun şekilde düzenleyip tekrar gönderebiliriz. İyi çalışmalar dilerim.
  11. Bu, app.config dosyanızdaki değerlerin çıkardığı sorunlardan biridir. Visual Studio'nun tekrar başlatılması çok büyük ihtimalle sorunu çözecektir.Bu noktada Visual Studio tekrar baslarken uyuşmayan config değerlerini(mismatched values) düzelteyim mi diye soracaktır. Yine de sorun devam ederse lütfen yazın.
×
×
  • Create New...