Projelerinizi nasıl düzenliyorsunuz? [kapalı]

Herhangi bir özel stil düzenleme projeniz var mı?

Mesela şu anda Bolivya’da birkaç okul için bir proje hazırlıyorum.

TutoMentor (Solution)
TutoMentor.UI   (Winforms project)
TutoMentor.Data (Class library project)

Projenizi tam olarak nasıl düzenliyorsunuz? Organize ettiğiniz ve gurur duyduğunuz bir şeye sahip misiniz? Çözüm bölmesinin ekran görüntüsünü paylaşabilir misiniz?

Başvurumun kullanıcı arayüzü alanında, farklı formlar ve ait oldukları yerleri düzenlemek için iyi bir şemaya karar vermekte zorlanıyorum.

Düzenle:

UE projesinde farklı formlar düzenlemeye ne dersiniz? Farklı formları nerede / nasıl gruplamalıyım? Hepsini projenin kök seviyesine koymak kötü bir fikirdir.

Bir proje tasarlarken ve mimariyi düzenlerken iki yönden başlıyorum. Öncelikle tasarlanan projeye baktım ve hangi iş problemlerinin çözülmesi gerektiğini belirledim. Kullanacak olan insanlara bakıyorum ve kaba bir UI tasarımı ile başlıyorum. Bu noktada verileri görmezden geliyorum ve sadece kullanıcıların ne istediğini ve kimlerin kullanacağına bakıyorum.

Bir kez ne istediklerini temel olarak anladıktan sonra, temel verinin ne olduğunu değiştireceklerini belirler ve bu veriler için temel bir veritabanı düzenine başlar. Sonra verileri çevreleyen iş kurallarını tanımlamak için sorular sormaya başladım.

Her iki uçtan bağımsız olarak başlayarak iki ucu bir araya getirecek şekilde bir proje düzenleyebilirim. Tasarımları bir araya getirmeden önce her zaman mümkün olduğunca ayrı tutmaya çalışıyorum, ancak her birinin ileriye doğru ilerlediği gereklilikleri de aklımda tutuyorum.

Sorunun her bir ucunu iyi bir şekilde anladığımda, sorunu çözmek için yaratılacak olan projenin yapısını oluşturmaya başladım.

Proje çözümünün temel düzenini oluşturduktan sonra, projenin işlevselliğine bakıyorum ve yapılan işin türüne bağlı olarak kullanılan bir dizi isim alanı oluşturdum. Bu, Hesap, Alışveriş Sepeti, Anketler vb. Gibi şeyler olabilir.

İşte her zaman başladığım temel çözüm düzeni. Projeler daha iyi tanımlandığında, her projenin kendine özgü ihtiyaçlarını karşılamaya çalışıyorum. Bazı alanlar diğerleriyle birleştirilebilir ve gerektiğinde birkaç özel alan ekleyebilirim.

SolutionName

.ProjectNameDocuments
    For large projects there are certain documents that need to be kept with
    it. For this I actually create a separate project or folder within the 
    solution to hold them.
.ProjectNameUnitTest
    Unit testing always depends on the project - sometimes it is just really 
    basic to catch edge cases and sometimes it is set up for full code 
    coverage.  I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
    Some projects have specific installation requirements that need to be 
    handled at a project level.
.ProjectNameClassLibrary
    If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
    I am adding this because I just found a need for one in my current project.  
    This project holds the following types of scripts: SQL (Tables, procs, 
    views), SQL Data update scripts, VBScripts, etc.
.ProjectName
    .DataRepository 
        Contains base data classes and database communication.  Sometimes 
        also hold a directory that contains any SQL procs or other specific 
        code.  
    .DataClasses
        Contains the base classes, structs, and enums that are used in the 
        project.  These may be related to but not necessarily be connected
        to the ones in the data repository.
    .Services 
        Performs all CRUD actions with the Data, done in a way that the 
        repository can be changed out with no need to rewrite any higher 
        level code.
    .Business
        Performs any data calculations or business level data validation,
        does most interaction with the Service layer.
    .Helpers
        I always create a code module that contains helper classes.  These 
        may be extensions on system items, standard validation tools, 
        regular expressions or custom-built items.  
    .UserInterface
        The user interface is built to display and manipulate the data.  
        UI Forms always get organized by functional unit namespace with 
        additional folders for shared forms and custom controls.

Projelerimi katmanlara ayırmayı seviyorum

Bu şekilde döngüsel bağımlılıkları yönetmek daha kolaydır. Örneğin, hiçbir projenin View projesini (katmanı) yanlışlıkla almadığını garanti edebilirim. Ayrıca katmanlarımı alt katmanlarda kırma eğilimindeyim. Yani tüm çözümlerim bunun gibi projelerin bir listesine sahip:

• Product.Core
• Ürün modeli
• Product.Presenter
• Product.Persistence
• Product.UI
• Product.Validation
• Product.Report
• Product.Web

Uygulamamın daha büyük "yapı taşları" dır. Sonra ad alanlarını daha mantıklı bir şekilde organize ettiğim her projenin içinde, ancak çok değişiyor. UI için çok fazla form oluştururken, boşluklu bir bölünme içinde düşünmeye çalışıyorum ve sonra her "boşluk" için ad alanları oluşturmaya çalışıyorum. Diyelim ki kullanıcı kontrolleri ve formları hakkında bir sürü kullanıcı tercihi var, onlar için UserPreferences adında bir ad alanına sahibim.

Projelerin Düzenlenmesi

Genelde dediğim gibi projelerimi ad alanına bölmeye çalışıyorum. Bir uygulamanın veya bileşenin her aşaması kendi projesidir. Çözümümü projelerime nasıl böleceğime nasıl karar verdiğimde , bu projelerin tekrar kullanılabilirliğine ve bağımlılığına odaklanıyorum . Ekibimin diğer üyelerinin bu projeyi nasıl kullanacağını düşünüyorum ve yolu oluşturduğumuz diğer projeler sistemin bir bileşenini kullanmaktan fayda sağlayabilir.

Örneğin, bazen bütün bir çerçeve kümesine (e-posta, kayıt vb.) Sahip olan bu projeye sahip olmak yeterlidir:

MyCompany.Frameworks

Diğer zamanlarda, çerçeveleri tek tek içe aktarmak için parçalara ayırmak isteyebilirim:

MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework

Formları Düzenleme

Bir UI projesi altında Formlar düzenlemek, projeniz genişledikçe gerçekten değişecektir.

• Küçük - Basit bir Form klasörü çok küçük bir proje için yeterli olabilir. Bazen, tıpkı sizin gibi, alanların adlarını değiştirebilir ve işleri olması gerekenden daha karmaşık hale getirebilirsiniz.

• Orta - Büyük - Burada genellikle formlarımı işlevsel alanlara bölmeye başlıyorum. Uygulamamın bir bölümünü bir kullanıcıyı yönetmek için 3 forma sahip, bir kısmı da futbol oyunlarını ve skorlarını takip eden bir bölüme sahipsem , Formlar> Kullanıcı alanı ve Formlar> Oyunlar alanını veya bunun gibi bir şeyim olur . Bu gerçekten, projenin geri kalanına, ne kadar ince taneli olduğumu ve ne kadar ince taneli olduğumu bildiğime bağlı.

Unutmayın, günün sonunda ad alanlarının ve klasörlerin, işleri daha hızlı organize etmenize ve bulmanıza yardımcı olmak için orada olduklarını unutmayın.

Gerçekten, ekibinize, projelerinize ve sizin için neyin daha kolay olduğuna bağlı. Genel olarak, sisteminizin her katmanı / bileşeni için ayrı projeler yapmanızı öneririm, ancak her zaman istisnalar vardır.

Sistem mimarisi hakkında rehberlik için, Microsoft'un Kalıpları ve Uygulamaları sitesini ziyaret edin.

.NET'te kod yazdığımda, ilgili işlevsellik kümelerine sahip olma eğilimim açık. Her biri aynı alt kümelere sahip olabilir. Ana grupları fiziksel olarak parçalamayı seviyorum - VS projelerinden bunlardan biri. Daha sonra montajları kullanarak mantıksal olarak alt bölmek. Bu modeli izleyerek, şu andaki projelerimden biri şuna benziyor:

• Wadmt (çözüm)
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Wadmt.Services
  • Wadmt.Tests
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Integration
  • Wadmt.Web

Umarım bu sizin için yararlıdır. Ayrılma seviyelerinin anlaşılması biraz zaman aldı.

Çözümlerinizi organize etmek için bir plan yapmak iyidir ve bunu yapmanın birkaç yolu vardır. Birden fazla projede paylaşılan ve kullanıcılarımız için tutarlılık sağlayan bazı işlevlere sahibiz. Proje organizasyonu yaptığımız işe bağlı. Özünde biz olacaktır:

Company (solution)
  Company.Common (shared library)
  Company.Project (Main application UI)
  Company.Project.UnitTests (Unit tests for all project modules)
  Company.Project.IntegrationTests (integration tests for all project modules)
  Company.Project.AutomationTests (tests that invoke the UI)

Oradan gerçekten kuruluma bağlıdır. Hem bir müşteri uygulamasına hem de web ön yüzüne sahipsek (sınıfta ya da diğer araştırmalarda kullanım sonuçlarını toplamak için yararlıdır), ortak olarak paylaşılan koda (yani serileştirilecek veri nesneleri) sahip bir projeye ihtiyacımız var.

  Company.Project.Model (ORM and business logic layer)
  Company.Project.Webapp (Web frontend/web service layer)
  Company.Project.WebClient (client code for web services)

Gerektiğinde diğer alt projeler eklenebilir. Dediğim gibi, bu gerçekten projeye bağlı. Bazı projeler gerçekten basittir ve sadece temel unsurlara ihtiyaç duyar. Keyfi proje ayırma ile mücadele etmeye çalışıyoruz, bu yüzden katmanlara ayırmak gerçekten mantıklı geliyor. Katmanlar, projeler, çözümler ya da eklentiler / uzantılar arasında paylaşılması gerekenlerle tanımlanır.

Buradaki birçok insanın KURU olduğunu düşünmemesi ilginçtir. Hayatımda birkaç kez, geliştiricilerin bu nedenle yapamayan dizin yapıları oluşturdukları oldu. Proje adını çözümden ve proje dizinlerinden uzak tutun!

İşte benim yolum:

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  

Uygulamamı tasarlarken, her zaman aralarında bazı bağımlılıkları olan modüller olarak görüyorum . Aklımda bir tasarım olduğunda, onu geliştirmek için aşağıdan yukarıya bir strateji kullanırım. Her bir modülü geliştiriyorum ve sonra birlikte çalışmasını sağlıyorum.

Peki, bu modüller şunlardır projeler benim altında solüsyon (genellikle sınıf kütüphaneleri ). Her modül farklı bir isim alanına ve kendi tasarımına sahiptir ( sınıfları , vb. İçerir).

Bu modüllerden biri GUI'dir ( Grafik Kullanıcı Arayüzü ).

Ayrıca her projedeki değişiklikleri izlemek için her zaman bir Revizyon Kontrol aracı kullanıyorum. Git'i öneriyorum . Açık kaynak kodlu, dağıtılmış ve kullanımı ücretsizdir.

Her yeni projeye başladığımda ne yapması gerektiğine dair geniş bir spesifikasyon elde ediyorum. Bu girdiyi elde etmek bana bir bağlam sağlayarak yardımcı oluyor, bu yüzden devam ediyorum ve proje hedeflerine ulaşmak için en iyi (veya en uygun) yöntemi düşünüyorum. Bu noktada, hangi desgin kalıplarının amaçlanan çözümü sağladığımı düşünebileceğini düşünmeye başladım. Proje için benim uygulayacağım tasarım kalıplarını dikkate alarak projeyi organize etmeye başladığım yer burasıdır.

Birkaç örnek:

1. Proje yalnızca girdi verisi ekranları oluşturmayı reddederse. Muhtemelen bir MVC paterni kullanırdım.
2. Eğer proje birçok kat platformunu destekleyen ağır hizmet arayüzü olarak kullanılacaksa, bir MVVM desgin paterni yardımcı olur.

Her birinin sizi projenizi belirli bir şekilde düzenlemeye zorlayacağını unutmayın.

İşte sizin için biraz okuma:

Net Tasarım Desenleri .

Tasarım Desenleri .

Nesneye Dayalı Tasarım .

Bu yardımcı olur umarım.