Çok kiracılı sistemlerinizdeki genişletilebilirliği nasıl yönetiyorsunuz?


13

Şu anda birkaç büyük web tabanlı çok kiracılı ürünüm var ve çok yakında kiracıya özgü birçok özelleştirmenin olacağını görebiliyorum.

Burada veya orada fazladan bir alan, belki de bir iş akışının ortasında fazladan bir sayfa veya fazladan bir mantık - bu tür bir şey.

Bu özelleştirmelerden bazıları temel ürüne aktarılabilir ve bu harika. Bazıları son derece spesifiktir ve herkesin yoluna girer.

Bunu yönetmek için birkaç fikrim var, ancak hiçbiri iyi ölçeklenmiyor gibi görünüyor. Açık çözüm, istemci başına çeşitli 'özelliklerin etkinleştirilmesine izin veren bir ton istemci düzeyinde ayar sunmaktır. Bunun dezavantajı, elbette, büyük karmaşıklık ve dağınıklıktır. Gerçekten çok sayıda ayar sunabilirsiniz ve zamanla çeşitli mantık türleri (sunum, iş) elden çıkabilir. Daha sonra, mevcut tablolara bir grup boş değerli alan eklemekten daha temiz bir şey isteyen yalvarmaya özgü alanlar sorunu var.

Peki insanlar bunu yönetmek için ne yapıyor? Force.com, genişletilebilirliğin ustası gibi görünüyor; açık bir şekilde süper genişletilebilir bir platform oluşturdular. Web tabanlı kullanıcı arayüzleriyle neredeyse her şeye ekleyebilirsiniz. FogBugz benzer bir şey yaptı, burada güçlü bir eklenti modeli yarattılar, ki bu aklıma aslında Force'tan ilham almış olabilir. Bunun için çok fazla zaman ve para harcadıklarını biliyorum ve eğer yanılmıyorsam, aslında gelecekteki ürün geliştirme için dahili olarak kullanmaktı.

İnşa etmeye cazip gelebileceğim ama muhtemelen yapmamam gereken bir şey gibi geliyor. :)

Takılabilir mimariye yapılan büyük yatırım tek yol mu? Bu sorunları nasıl yönetiyorsunuz ve ne tür sonuçlar görüyorsunuz?

EDIT: Görünüşe göre FogBugz oldukça sağlam bir platform oluşturarak ve bunu ekranlarını bir araya getirmek için bunu kullanarak ele almış gibi görünüyor. Bunu genişletmek için ISearchScreenGridColumn gibi arabirimleri uygulayan ve bir modül haline gelen sınıfları içeren bir DLL oluşturun. Eminim büyük bir geliştiriciye sahip oldukları ve aylarca üzerinde çalıştıkları düşünülerek inşa etmek çok pahalıydı, ayrıca yüzey alanları belki de uygulamamın boyutunun% 5'i.

Şu anda, Force.com'un bununla başa çıkmanın doğru yolu olup olmadığını merak ediyorum. Ve ben sert çekirdekli bir ASP.Net adamıyım, bu yüzden bu kendimi bulmak için garip bir konum.


3
Sanırım bu SO sorusu, bu bir özdeş çapraz yazı yapar. Farklı cevaplar arıyorsanız Bunu yapma, ya bize, SO soru burada göç almak isteyecek, ya tam olarak SO soru üzerine cevaplar tatmin edici değil neden.
yannis

Haklısın, soru Programcılar'da daha iyi, ama yine de oldukça iyi cevaplar aldın gibi görünüyor. Soruyu SO sorusuna referans vermek için düzenledim.
maple_shaft

Yanıtlar:


8

Benzer bir sorunla karşılaştım ve size bunu nasıl çözeceğimi anlatacağım.

  1. İlk olarak, bir "çekirdek" kütüphane veya motor vardır. Bu temelde şovu zaten anladığınız gibi çalıştırır. Formları dinamik hale getirmekten, kullanıcı ve hesap yönetiminden, rollerden, adlandırdığınızda, yapar, her sistemde ortak olan şeyleri işler.

  2. Sistemin her parçası bir modül içinde bulunur. Bir modülün bağımlılıkları vardır (bağlı olduğu diğer modüller). Örneğin, "çekirdek" sistemde Güvenlik (kullanıcılar, gruplar, roller, parola ilkeleri), Yerel Ayarlar (çeviriler, ülkeler, kültürler), Dosya Deposu, E-posta vb. Vardır. Her modül kendisini bir xml dosyası kullanarak tanımlar. Xml dosyası temel olarak şemaları, tabloları, hesaplama sınıflarını, ekran tanımlarını vb. Belirtir. Bunlar , dosya tarihi değiştiyse uygulama başladığında okunur .

  3. Müşteriye özel modüllerin kendi xml dosyaları ve kendi DLL'leri vardır. Hepsi artı ve sistemin geri kalanına uygun ve şeffaf bir şekilde çalışır. Mevcut MVC görünümlerini özel kodlarla ve özel kod ve özel görünüm modelleriyle değiştirmek için aşağı doğru.

  4. Bir müşteri mevcut işlevselliği genişletmek istiyorsa, xml / system bir modülü diğerinden "türetebileceğim" bir yöntem sağlar. Yeni modül varolan tüm işlevselliğe sahiptir, ancak müşterinin yeni bir DLL'deki özel gereksinimleri ve değişiklikleri yapabilen genişletilmiş bir XML dosyası ile. Uyarı, bu sistemdeki mevcut alanları gerçekten kaldıramazlar, ancak onu genişletebilir ve tamamen yeni nesneler ve işlevsellik sağlayabiliriz.


+1: Kulağa bir iki saat sürdü. :)
Brian MacKay

1
@BrianMacKay, iş bir kez yapıldıktan sonra (ve bir slog oldu), müşterilerimiz özelleştirmeleri dönebildiğimiz hızdan çok memnun kaldılar. MVC çerçevesinin (görünümler / sayfalar söz konusu olduğunda) çok projeli olmaları için çok iyi kredi sağlamadığını unutmayın. SVN'nin mülk özelliklerini kullanarak ve çekirdek depodan getirilen çekirdek görünümlere sahip olduk ve bunu özelleştirmek için CSS / düzenleri kullandık. Ama yıl, iyi bir kaç saat: P
Moo-Juice

Sadece merak ediyorum, mimarlığın kendisinin uygulanmasının ne kadar sürdüğünü ve kaç geliştiricinin dahil olduğunu düşünüyorsunuz?
Brian MacKay

1
@BrianMacKay, 5 aydı. Tüm CSS / HTML / Kısmi görünümleri, javascript vb. Yapmak için bir UI geliştiricisi ve gerisini yapmak için bir arka uç geliştiricisi (kendim).
Moo-Juice

4

Yönetmek için çok sayıda sürüm mantığına ve kod katmanlarına sahip olmak web uygulamanıza / sitenize değer katmaz. Ayrıca, neler olup bittiğini anlamak için daha fazla beyin gücü gerektirir ve sizi yaptığınız işin özünden uzaklaştırır.

Ben farklı tavsiye ediyorum. Karmaşık olan şeyleri basit tutmanızı tavsiye ederim.

Herkes için aynı olan tek bir kod tabanı oluşturun. Eklediğiniz her özellik herkes için bir özelliktir. Özelliklerin değil, yalnızca öğe sayısını veya depolama alanını veya ölçülebilir bir şeyi kısıtlayın. Bunun nedeni, depolama, veri girişi sayısı vb. Bazı özellik mantığı yapmak yerine yalnızca öğelerin eklenmesi üzerine programlanmalıdır. Özellikler başka özelliklere bağlıysa ne olur? Bunu kodlamak çok karmaşık hale geliyor.

Cevabımı nitelemek için, birçok müşteri için sahip olduğum bir e-ticaret çerçevesi oluşturdum ve tüm kimliklerini korumak için zor yolu öğrendim. Zinciri kırdım ve e-ticaret için çok tennant olan tek bir yönetim web sitesi oluşturdum. Daha sonra web servis çağrılarından veri çeken web sitelerine sahibim. Bu, farklı teknolojilerdeki farklı ekiplerin e-ticaret siteleri için belirli özellikleri uygulamalarına izin verirken, her ay aynı altyapı üzerinden ödeme almaya devam ediyor ve ne yaptıklarını umursamıyorum. Sadece özellikleri değil, sayıları kısıtlıyorum. Yolu daha kolay. Müşteri, web sitesini oluşturmak için kendi satıcısını seçebilir ve artık bu kararlara katılmıyorum.

Ayrıca içerik yönetimi SAAS için bir abonelik hizmetim var. Bu, kullanım katmanlarına göre de çalışır ve ekibim herkes için daha fazla özellik eklerken, istedikleri takdirde müşteriler kendi eklentilerini ekleyebilir.

Bu, çok uzun bir süre sonra kafamı duvara vurmaktan, daha sonra basit bir şeye tökezlemekten sadece benim deneyimim.

Her müşteri için bir şey her zaman spesifik olacaksa, bunun için bir çerçeve oluşturmayın. En basit parçalarına ayırın, böylece çerçeve kısmı herkes için çalışır ve gerisini kesin, böylece birey için genişletebilirsiniz.


Deneyiminizi paylaşmak için +1. Duyduğum şeylerin çoğu "bu çok zor bir problem." Gerçekleştiğim gerçek şu ki, bu sistem tonlarca özelleştirmeye sahip olacak ve hepsi herkes için uygun değil ... Görünüşe göre bir hizmet katmanını açığa çıkarma ve ardından insanların bunu tüketmesine izin verdiğinizi söylüyorsunuz. ancak istedikleri gibi - en azından tüm uzantıları dahili olarak yazma avantajım var. Ama hala yönetmek için bir karışıklık (cntd)
Brian MacKay

Sonuç olarak, kendi UI bileşenleri ve dinamik kompozisyon kavramını destekleyen bir platform yazmanız ve ardından tüm uygulamayı bu platformu kullanarak oluşturmanız gerekecek. Ve bu yüzden her şeyi force.com'a yazmanın akıllı olacağını düşünmeye başlıyorum, çünkü force.com budur!
Brian MacKay

Merak ediyorsanız Brian, FYI kitgui.com ve hubsoft.com.
Jason Sebring

2

Üzerinde çalıştığım yazılım ürününde kullanıcı genişletilebilirliği için fazladan alanlar var. Bu alanlara ilişkin her veri öğesi, uygulamadaki ana tablolarda var olan bir satıra anahtarlanabilir. Örneğin, yazılımınızda müşteriler ve her müşteri bir sipariş listesi içeriyorsa, özelleştirilebilir veri tablosunda, müşteri tablosuna ve sipariş tablosuna yabancı anahtarlar için bir sütun bulunur; bunlardan yalnızca biri boş kalır. Bu ya da her biri bir tablo için özel alanlara sahip bir dizi tablo.

Bu, kullanıcı için fazladan veri depolamanın basit ve etkili bir yoludur. Bu alanların adları ve türleri hakkında ek bilgilerin depolanması gerekir.

Bu, bir müşterinin özel alanlarını kapsar. Özel davranış için, bir web hizmetleri API'sı uzantılara izin verir.


1

1) Başkalarının kodunu sahip olduğunuz kutularda çalıştırmak oldukça zor bir sorundur. Ya onlara güvenebilirsiniz ya da sorumluluğu makul bir şekilde erteleyebilirsiniz, kodlarını çok fazla korumalı hale getirmeniz ve ortalamanın üzerinde güvenlikten daha yüksek bir adanmışlığınız olması gerekir. Eklenti sisteminiz daha fazla işleve izin verdiği için, onu güvenli hale getirmenin zorluğu artar. Hizmet reddi (eklentiler çok fazla kaynak tüketir), bilgi sızıntısı (eklentiler diğer kiracıların verilerine erişebilir) vb. Çok gerçek ve zahmetli olabilir, insanları çok tanımadığım sürece buna katılmazdım bu sorunları ya da doğru anlayabilmek için çok zamana sahip çok yetenekli insanlar.

2) Evet, modülerlik ve özelleştirilebilirlik zordur. Strateji modeli gibi şeyler yardımcı olabilir (işlev işaretçileri için süslü bir ad; Java'da genellikle sınıfın kullanıcılarının kodunuzun davranışını özelleştirmek için uygulayabileceği bir Arabirim bildirerek uygulanır), ancak çok izole ve ayrıştırılmış istersiniz bunun çalışması için kod.

3) Veri açısından, bu, şematik depolamanın yararlı olabileceğinin örneklerinden biri olabilir. İlişkisel bir veri modeliniz varsa, farklı müşteriler için çok sayıda sütun içeren tablolara sahip olmak sorunludur (evet, çok sayıda boş değerli sütunla sonuçlanırsınız, bu da kötüdür ; bunun bir nedeni, doğru kısıtlamaları ayarlamanın zor veya imkansız olmasıdır [ör. geçersiz null kombinasyonlarının görünmesine izin vermeyen kısıtlamalar]). (Yani müşteriye özel tablo ekleme usersve foo_usersbirlikte, userstüm müşteriler için geçerli alanları tutarak ve foo_usersdaha da Foo belirli fileds sahip); kolayca doğru kısıtlamalara sahip olabilirsiniz, ancak RDBMS'niz bunu düzgün bir şekilde ele almayabilir (patlama, tablo sayısı sınırlamaları vb. nedeniyle) ve muhtemelen kodunuzda çirkin görünecektir.

Sonuç olarak, RDBMS'nizde veri modelinizi daha az ilişkisel ish yapan ve rahatsızlığa neden olacak bir anahtar / değer deposu uygulayabilirsiniz (ilişkisel veritabanları ilişkisel ish modelleriyle en iyi şekilde çalışır). Bir NoSQL çözümünün genel olarak soruna uygun olup olmayacağından emin değilim, ancak çoğu uygulamanın şematikliği bir avantaj olabilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.