Mimari (yapı) yönelimli ve özellik odaklı proje yapısı

14

Katıldığım proje, mimari odaklı bir projenin dosya / klasör yapısına sahip:

Root
|____ Node1
    |____ Event Handlers
    |         |___ <all event handlers of project>
    |____ Events
    |         |___ <all events of project>
    |____ Request Handlers  
    |         |___ <all request handlers of project>
    |____ Requests
    |         |___ <all requests of project>
    |____ ...

Sistemin mimari bakış açısından açıktır (geliştirme ekibi tarafından önerilmiştir).

Tasarımcı ekibi tarafından öne sürülen özellik odaklı bir yapıdır:

Root
|____ Feature #1
    |____ Event Handlers
    |         |___ <all event handlers of Feature #1>
    |____ Events
    |         |___ <all events of Feature #1>
    |____ Request Handlers  
    |         |___ <all request handlers of Feature #1>
    |____ Requests
    |         |___ <all requests of Feature #1>
    |____ ...

Bu varyant tasarımcılara daha yakındır ve uygulanacak bir özelliği açıkça tanımlamaktadır.

Ekiplerimiz kutsal bir savaşa başladı: en iyi yaklaşım nedir. Birisi bize yardımcı olabilir ve birinci ve ikinci olanların eksilerini ve artılarını açıklayabilir. Belki de ikimiz için daha yararlı ve faydalı olan üçüncü bir tane var.

Teşekkür ederim.

project-structure

— zzz
kaynak

Her iki yapıyı da anlamıyorum - Olaylar ve İstekler (ve dolayısıyla Olay İşleyicileri ve İstek İşleyicileri) arasındaki fark nedir?

— Peter Boughton

1

Çok net bir soru - ve tarafsız!

— Michael K

1

Ölçeklenebilirlik açısından, ikinci yaklaşımın yatay olarak ölçeklendirilmesi oldukça kolay olmalıdır.

— CodeART

11

İkincisine oy verirdim. Birinci yapıda, için olay işleyicileri, olay işleyicileriyle FeatureAtamamen ilgisizdir FeatureB. Geliştiricilerin bir kerede tek bir özellik üzerinde çalışacağı ve bir FeatureXistek üzerinde çalışıyorsanız, bir FeatureXistek işleyicisini, örneğin bir FeatureZistekten daha ince ayar yapmanız gerekeceği çok daha muhtemel .

Bu arada, bu soruyu tarafsız bir bakış açısıyla nasıl sorduğunuzu seviyorum.

— Kendine not - bir isim düşün
kaynak

1

Bir uyarı ile +1: küçük projeler için, ikincisi, koymak için dosyalar olduğundan daha büyük bir dosya yapısına neden olur. İlk olanlar için kullanırım.

— Michael K

@Michael katılıyorum, ancak bu durumda büyük bir proje.

— Zzz

1

+1: Ve eğer bir kullanıcı / müşteri ile sohbet etmek zorunda kalırsanız, o zaman terminoloji oldukça tutarlı olabilir.

— Steven Evers

4

İkinci yaklaşımdan her zaman daha rahat geçirdim, ama her zaman gerçekten paylaşılan / temel sınıflar için genel veya ortak olarak adlandırılan bir “özelliğim” var.

Yaklaşım iki gerçekten ayrı şeyleri ayrı tutar, ancak "ortak" alan olmadan bazen şeyleri iyi uymayan alanlara ayırır.

— fatura
kaynak

Ortak ve genel için +1 (her projenin genel yardımcı programları, araçları vardır ...)

— Zzz

3

Özellik mucitleri uygulama ayrıntılarını neden önemsiyor? Eğer bu argümanın yanları arasındaki ayrım ise, o zaman cevabın açık olduğunu düşünüyorum. Fikir / özellik icat eden kişiler, uygulayıcıların ihtiyaç duyduğu dosya yapısını belirlemez.

Bu, bir özelliğin uygulanması birden çok dll, exes, veritabanı veya diğer yazılım parçalarını kapsadığı zaman özellikle önemli bir konudur.

— John Fisher
kaynak

1

Bunu düşündüm, ancak diğer her şey eşit olduğunda, ikinci yaklaşımın en önemsiz uygulamalar dışında herkes için açık felsefi avantajları var. En azından iyi bir öneri.

— Robert Harvey

@Robert Harvey: Projenin düşünsel organizasyonu hakkında konuşuyorsanız, o zaman yeni bir cevap düşünmem gerekecekti. Ancak, kod içeren dosyalardan bahsediyorlar gibi görünüyor ...

— John Fisher

Anahtar, özelliklerin farklı kovalara ayrılmasıdır. En küçük uygulamalar dışındaki herkes için, ister bir klasör yapısına, bir sınıf yapısına veya bir ad alanı kuralına atıfta bulunun, böyle bir organizasyona ihtiyacınız olacaktır.

— Robert Harvey

1

@Robert Harvey: Yapım ve dağıtım sorunları ne olacak? Kodu yazmak ve hatalarını ayıklamak için yalnızca bir IDE kullanabilmek gibi daha basit şeylere ne dersiniz? Bunlardan bazılarının klasör yapıları üzerinde güçlü bir etkisi olmalıdır.

— John Fisher

1

İki seçenek göz önüne alındığında, ikinci yaklaşımı kabul etmelisiniz. İlki sadece şekilsiz bir damla gibi görünüyor. En azından ikincisinin bir şekli var.

Bu gerçekten projenin ne kadar büyük olduğuna bağlı. "Özellikler" büyükse, her birinin kendi ayrı kovası gerekir.

— Robert Harvey
kaynak

1

Kullandığınız terminolojiyi anlamıyorum, ama yine de cevap vermeye çalışacağım, çünkü her iki yapı da yanlış bir yaklaşım gibi görünüyor.

Sadece bir avuç özelliğiniz olmadığı sürece, bunları kategorilere ayırmanız gerekir ve bu her iki tasarımda da ikram edilmez (Düğüm1'in amacı bu değilse, ancak "projenin tüm X" i önermektedir) Aksi takdirde, WTF olduğunu merak ediyor - bir Node2 var mı?)

Ben böyle bir şey düşünebilirsiniz:

Root
|____ Event Handlers
|   |____ Category A
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Category B
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|
|____ Events
|   |____ Category A
|   |    |___ Feature #1 Events
|   |    |___ Feature #2 Events
|   |    |___ Feature #3 Events
|   |
|   |____ Category B
|   |    |___ Feature #4 Events
|   |    |___ Feature #5 Events
|   |
|

Veya bu:

Root
|____ Category A
|   |____ Event Handlers
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Events
|        |___ Feature #1 Events
|        |___ Feature #2 Events
|        |___ Feature #3 Events
|   
|____ Category B
|   |____ Event Handlers
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|   |____ Events
|        |___ Feature #4 Events
|        |___ Feature #5 Events

Ama ikisi de tamamen kapalı olabilecek varsayımlar yapıyorlar - sorunuzu daha fazla ayrıntıyla güncelleyebilirseniz fikrimi değiştirebilirim. :)

— Peter Boughton
kaynak