Şu konularda sağlam bir eğitim seti, eğitim falan olsa gzümü kırpmadan alıcam. İnternette papağan gibi konulardan, eğitimlerden başka bir şey yok. Şurda bahsi geçen 2-3 konsepti derli toplu anlatan bir tane ücretli-ücretsiz kaynak bulamadım. Nice babayigitler kirayi kim odeyecek, coluk cocuk ne yiyecek derdinden dolayi dunyayi degistiremiyor.

Hocam sorduğun soru ASP. NET Core veya başka bir geliştirme ortamı/ürün den bağımsız bir soru. Buradaki veri organizasyonunu, izolasyonunu, güvenliği vs. kendin halledeceksin. Bir CRM uygulaması yaptığını varsayalım. Şirketler, müşteriler ve kullanıcılar olsun. Kullanıcılar sisteme login olan kişiler yani şirketlerin çalışanları. Muhasebeci, satış elemanı veya müşteri destek elemanı gibi rollere sahip olabilirler. Müşteriler şirketlerin müşterisi. Bireysel veya kurumsal müşteri olabilir mesela. Her müşterinin bir profil sayfası var. Sen oraya adres, iletişim bilgileri vs gibi bilgileri yazıyorsun. Veya müşteriye zel not ekliyorsun. Müşterilerin sisteme giriş yapamadığını varsayalım. CRM uygulaması sadece şirketlerin çalışanları için yani kullanıcılar için. Şirketler ise bu CRM e para deyen kurumlar. Her şirketin 1 adet admin hesabı olur ve diğer kullanıcıları o admin hesabı oluşturur mesela. Burada sen daha işe başlarken A'dan Z'ye herşeyi bir multi-tenant uygulamanın prensiplerine gre geliştireceksin. Veritabanında müşteriler diye bir tablo açtıysan bu tablonda "company_id" isminde bir kolon olacak. Ve bu kolon indexli olacak. Neden? Çünkü sen sıklıkla "Seçilen şirkete ait müşterileri getirme" işlemini yapacaksın. Tabloda 100.000.000 satır müşteri olsada sorun olmaz. Neden çünkü sen company_id alanını indexledin. Gelelim Authentication ve Authorization konularına. Yani kimlik kontrolu ve yetki kontrolu. Diyelim senin müşteri sayfanı gsteren URL şu şekilde; www.crmprojesi.com/mycompany/customer/176 buraya sisteme login olmamış bir insan giriş yapamayacak elbette. Ama asıl dikkat etmen gereken nokta Authorization konusu. Diyelim sisteme giriş yapmış 2 farklı kullanıcı var. Bunlardan 1 tanesi gider adres satırındaki 176 yı 350 yaparsa doğrudan 350 numaralı müşteriyi grememesi lazım!! Sen her gelen istekte "Acaba bu user bu işlemi yapmaya yetkili mi? Ulaşmak istediği müşteri acaba gerçekten bu user ın dahil olduğu şirkete ait bir müşteri mi?" diyerek kontrol etmen lazım. Bu kontrolü ASP. NET Core üzerinde nerede yapacağın sana kalmış. İstersen Action Metodun üzerine yazdığın bir filtre içinde yaparsın, istersen business katmanında yaparsın. Bu tamamen senin uygulamanı nasıl yazdığına bağlı. Kullandığın mimariye vs. Tek veritabanı mı yoksa her şirket için ayrı veritabanı mı diyecek olursan, buna cevap senin projene gre değişebilir. Artıları ve eksileri var. Ve seçtiğin projeye gre değişir. Bu tarz CRM, üye ynetimi gibi yazılımlarda tek bir veritabanı kullanmanı tavsiye ederim. Multi tenant uygulamalarda her müşteri için ayrı veritabanı olması bakım vs işlerini inanılmaz zorlaştıracaktır. Ancak analytics tarzında bir ürün yaparsın. Çok çok yoğun bir şekilde veri yazma vs işlemleri olur o zaman her bir müşterin için gider yeni bir veritabanı açarsın. Ayrıca tek bir veritabanı açıp, dileyen müşterilerin kendi veritabanlarını kullanabilecekleri bir yapı da organize edebilirsin. Hibrit şekilde yani. Bu soru dil veya platform bağımsız bir soru. ASP. NET Core, Php, Java vs farketmez. Kafanda kuracaksın herşeyi.

Loglama yı da kolaylaştırıyor, softlocking dediğimiz sistemide. rneğin ayni kaydın edit ekranina 2 kişi birden girdi. bir kişi kaydın x parametresini güncelledi. diğer kişi y parametresini ve kayıt tuşuna basti. son kaydeden ilk kaydedenin değşikliğini ezecektir. Fakat, update sorgusunun içinde UpdateAt değişkeninin kendi record'u actiği ilk andaki değişkenden daha ileri bir tarih olmasinin kontrolu var ise 2. kaydedenin updatedAt tarihi ilkinden nce olacağindan sorgu hata dndürecek. Kayıt başarsız ekranına kişi dnecek. O anda sizden once XXX kişisi bu kaydi güncellemiştir bilgisinin gidip x bir logdan gsterilmesinden ise direk tablodan okunmasi hem işi kolaylaştırıyor hemde bir cok hatanın nüne geciyor. bu tarz uygulamalarin en değerli parcasi oluyor ORM. framework ekibi kenti tarafında bu tarz işleri filtreler ise üst katman da ki yazılımcı arkadaşlar isteseler bile yanlış kişiye yanliş datayi cikartamazlar. Bu sayede deneyim eksiği olan yazılımcıları bile gnül rahatlığı ile interface veya form kodlamada kullanabilirsin. Maliyetlerini düşürürsün. Loglama konusunda ise patronum dehşet takintili. Her gelen request bir tabloda loglanir. Buna cevap giden response da loglanır. Bu requestin loglandığı tabloda ki GUID ile de db ye giden her query farkli bir tabloya loglaniyor bu sayede db bir sorun yaşanırsa gerekirse loglardan bu datalari tekrar oluşturabiliriz bile. Record da ki change işlemleri de ayni bir tabloda tekrar loglanıyor. Bu da recordun historysini gstermek için. rneğin bir ürünün fiyatinda ki değişiklileri kimin yaptiğini vs direk bu tablodan filtreleyerek getirebiliyoruz. Sektrü bilmiyorum ama deme sektründe sertifikasyonlar gereği loglarin 5 yil saklanması gerekiyor. Kurum ile calismayi biraktiğinda senden logları istiyor. O durumda logları filtreliyip çekmen gerekiyor. Bunda dolayı log tablosunda da bu logu oluşturan kişinin kim oldugunu, bu log'un değiştirilmediğinin delili olarak zaman damgasini vs de koyuyor olman gerekli. dalyKadir tarafından 05/Tem/21 20:34 tarihinde düzenlenmiştir

Her bir kıymetli yorumunuz ayrı ayrı için teşekkür ediyorum. @coder2 Banada farklı db'lerden ilerlemek mantıklı olabilir gibi geliyor ama başlangıçta iyi olsada kullanıcı sayısı belli bir seviyeyi aştığında işleri ynetmek zorlaşır gibi düşünüyorum. Tek uygulama tek db iyi gibi ama bu noktada yapılacak konfigürasyonların iyi ayarlanması gerekiyor sanırım. @Hannibal_King "Seçilen şirkete ait müşterileri getirme" olayı her işlemde kontrol edilecek gibi grünüyor. Authorization konusu için dediğin custom attribute yazıp her bir request'te gelen requesti kontrol ederek header veya cookie üzerinden gelen bilgiler ile ynlendirme yapılması gibi bir yntem geliyor aklımıza. Uygun mudur bu hocam? @MadJack asp. net boilerplate artık. net core için abp.io üzerinden devam ediyor. Ve dediğiniz gibi multi-tenancy yapısı hazır geliyor hatta başlangıçta proje için istenilen ui-frameworkü ve istenilen DB türüne gre template bir proje oluşturuyor. https://abp.io/get-started Ama Junior seviyedeki bir geliştirici için abp.io bence kompleks bir yapıda kalıyor. DDD konseptlerine ve bir takım gerekli programlama yetkinliklerine tam hakim olmadan abp.io üzerinden geliştirme yapmak sıfırdan bir multi-tenant projeye girişmekten çok daha zor grünüyor. Ama abp.io işlerinizi kolaylaştıracaktır. abp.io üzerinden devam etmelisiniz tavsiyesi gelirse buna mutlaka dikkat ederiz hocam @manglerman ElasticSearch kullanmadım hiç ama MongoDb'deki yapı tablolara kıyasla daha esnek olduğu için kullanılabilir gibi ama çok hakim değilim mongodb'ye de ilk çıktığı zamanlar authorization felan yoktu diyorlardı o zamanlarda güvenlik sıkıntıları vardı galiba doğru mu hatırlıyorum bilmiyorum ama şimdi byle sıkıntıları kalmamıştır tabi. Kurguyu baştan iyi tasarlamak gerek sanırım DB yapısı, authorization işlemlerinin nasıl izole edileceği, her bir tenant için ynetici- kullanıcı yapılandırması, yoksa direkt girişip yapılabilecek bir iş gibi durmuyor. Yine fikir almak için buraya mutlaka yazacağım hocam, teşekkürler. @dalyKadir Son bahsettiğin Auditing ile mi ilgili hocam. Şyle bir kütüphane buldum ama yapısı kompleks geldi bana https://github.com/thepirat000/Audit. NET Multi - tenant yapılarda Logging o kadar nemli mi hocam. Her hareketin bir yerlerde tutulması gerekiyor mu? Yoksa ben konuyu yanlış mı anladım? Https tarafından 05/Tem/21 19:02 tarihinde düzenlenmiştir

https://www.devarchitecture.net/Engün Demiroğun ekibiyle başlattığı proje. İşini grebilecek güzel bir girişim. https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/introduce-eshoponcontainers-reference-appMicrosoftun referans projesi gerçekten büyük bir yapı kuracağım microservis mimarisi ile uçup kaçacağım dersen ekibinle! bu altyapıyı kullanabilirsin. Ücretsiz: https://aspnetboilerplate.com/Ücretli: https://abp.io/Yine Türk geliştiricilerin platformu olan bu boilerplate i de kullanabilirsin lakin bunun için know how gerekli yahut yapıyı ğrenme süreci gerekir. kıymetli yorumunuz için teşekkürler hocam, abp.io da ücretsiz hocam ama commercial sürümü ücretli. boilerplate. net framework, abp.io. net core üzerine kurulu. yine dediğim gibi abp.io drt drtlük bir multi-tenant yapısıyla geliyor hatta projenin ui frameworkü bile seçilebiliyor ancak ben gerek DDD yapısı gerekse diğer konularda oldukça zayıfım hocam. ncelikle temel yapılarlar ile birlikte kendi kurgulayacağımız multi-tenant yapısıyla daha iyi olur düşüncesindeyiz henüz. abp.io da gelen hazır yapıya, DDD ve diğer prensipleri tam kavramadan girişmeyi uygun gremedik, arkadaşımda bende. Ama illa kullanın çok büyük kolaylık sağlarsınız derseniz, deneriz mutlaka hocam. edit: devarchitecture ı bilmiyordum, inceliyorum hocam. Https tarafından 16/Tem/21 01:53 tarihinde düzenlenmiştir

En uygun model projenin içeriğine gre değişir. Vakit varsa tüm yaklaşımlar için yazılmış blog yazılarını veya makaleleri okuyup, açık kaynaklı projeleri inceleyip yle karar vermek gerekir. Basit bir rnek, binlerce/milyonlarca tenant ve her tenant için 1-2 kullanıcı beklenen B2B bir uygulama için veritabanlarını tenantlara gre ayırmak mantıklı olmayacaktır. Fakat tenant sayısı grece az, her tenant için binlerce kullanıcının olduğu senaryoda tek veritabanı daha mantıksız bir seçim olur. Uzun zaman nce ASP. Net Boilerplate adlı bir projeyi incelemiştim. Geliştiriciye mimari altyapıyı hazır eden, multitenant desteği de olan başarılı bir projeydi. Halen devam ediyor ve. net core desteği sunuyorsa gz atmanızı tavsiye ederim. Everyone sees just what they want to see.

paylaştığın imajdaki 1. yntem iş gücü mantık ve ynetilebilirlik açısından en mantıklı olandır. ayrıca benimde projelerimde uyguladığım yntemdi. yeni bir company ekleyeceğin zaman yazdığın admin kodundan başka bir hiç bir tool kullanmayacağın anlamına gelir. eğer her company'de milyonlarca kayıt olacak db şişecek gibi bir düşüncen varsa identity bilgileri hariç mongodb veya elastic gibi nosql toolara ynelebilirsin. ve companyid kolonuna gre sharding yapabilirsin. bylece her company'e zel bilgiler kendi shard'ında bylece bir business ile ilgili sorgu yaptığında sadece o business'a zel sanal bir db içinde sorgu yapmış olursun. ama dbyi tek başına ynetirsin. replicalar node'lar filan tek yerden ynetilmiş olur. ama resimdeki ikinci yntemi kullanırsan her yeni company oluşturduğunda onunla ilgili bir db oluşturman lazım. batch bile olsa yeni bir db ayağa kalkacak ve ynlendirmeler o dbnini backup maintenance ayarları vb derken ortalık karışabilir. KARIŞIR demiyorum ama işgücün baya artar. son 6 yılı ekip lideri olmak üzere 8 yıldır multitenant projelerde çalışıyorum aklına ne gelirse sorabilrsin her konuda yardımcı olmaya çalışırım. türk kızlarından sabun yapalım, rus kızları elini yıkasın.:)

https://www.devarchitecture.net/Engün Demiroğun ekibiyle başlattığı proje. İşini grebilecek güzel bir girişim. https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/introduce-eshoponcontainers-reference-appMicrosoftun referans projesi gerçekten büyük bir yapı kuracağım microservis mimarisi ile uçup kaçacağım dersen ekibinle! bu altyapıyı kullanabilirsin. Ücretsiz: https://aspnetboilerplate.com/Ücretli: https://abp.io/Yine Türk geliştiricilerin platformu olan bu boilerplate i de kullanabilirsin lakin bunun için know how gerekli yahut yapıyı ğrenme süreci gerekir. Paslanmış bir uygulama geliştirici.. #AnalistŞart

Code first ile oluşturulmuş 2 tablo var; Müşteriler ve MüşteriTalepleri diye. Başlangıçta birbirlerine bağlı olmayan bu iki tablo için sonradan birbirlerine bire çok olarak bağlandığında. Müşteri talepleri tablosunda veriler varken yeni bir kolon oluşacak. Ve nceki satırlarda FK alanı boş olacağı için sorun oluşuyor. En baştan verileri el ile girmek gerekiyor. Byle bir durumda nasıl bir yntem izlenmesi gerekiyor? Bire çok ilişki durumlarını 3. bir tabloda tutmadan nasıl bir yol izlenir. Tabloda sonradan açılan bu FK alan boşa düşüyor. Projeyi sunucuya gnderdikten sonra byle durumlarda nceki verileri kaybetmeden yeni güncellenen yapıya nasıl geçiş yapılır.

Up olsun. net core bilmiyorum ve multi-tenant bir proje içerisinde hiç yer almadım. Bununla beraber baya araştırdım ve tek app üzerinden her müşteri için ayrı DB de verileri tutmak bana daha doğru geliyor. İleride tek DB de birleştirmek istenirse bu pek mümkün olmayacaktır ama yalıtım ve ynetilebilirlik açısından daha doğru geliyor. nceleri Kızlar Utanınca Kızarırdı Şimdilerde Kızarınca Utanıyorlar..

. net core ile multi tenant bir uygulama geliştirileceği zaman nasıl bir yol izlenmesi gerekiyor. Kullanıcı girişleri, veritabanları, middleware lar, yine farklı kullanıcı grupları için tutulan verilerin bütünlüğü ve bu verilerin izolasyonu, soyutlanması vs. Multi tenant uygulamalar için farklı yaklaşımlar var sanırım; En uygun model hangisidir ve bu uygulanış şekli nasıldır? Asp. net core için rnek projeler var mıdır? Https tarafından 26/Haz/21 21:05 tarihinde düzenlenmiştir

Burada senin kullandiğin alt yapi ve database türü de nemli. 40 müşteriye hizmet verdiğin zaman her müşterinin app'inin güncellemesini, app db versionunun takibini vs yapmak sıkıntı. Her db nin yedeklenmesi osu busu derken iş gücünü artıracaktır. @manglerman 'in da dediği gibi 1. yapı en güzeli geliyor bana. Bizde bir projede buna benzer bir yapi kullanıyoruz. Birazda esneklik kattık. Entityframework'den türeyen bir ORM yapısı kullanıyoruz biz. Login olan kullanıcının mevcut Müşteri kodu ne ise, her select ve insert querysinin sonuna otomatik ekltiyoruz bu sekilde yanlış bir kullanıcı başka bir kullanıcının datasina ulaşamıyor-değiştiremiyor. Tabi her tabloda merchantCode, createdBy createdAt, updatedBy, updatedAt kolonlarıda oluyor. Eğer kullanıcının profiline bir connection string tanimlandi ise, db ye o connection string ile bağlandığı için kullanıcı tablosu ortak olsa bile, application datalar istenildiği an ayrıla biliyor. Oracle bunun için biçilmiş kaftan. dalyKadir tarafından 28/Haz/21 19:57 tarihinde düzenlenmiştir