it-swarm.asia

Projelerinizi nasıl düzenliyorsunuz?

Proje düzenleme tarzınız var mı?

Örneğin, şu anda Bolivya'daki birkaç okul için bir proje hazırlıyorum, bunu şu şekilde organize ettim:

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

Projenizi tam olarak nasıl düzenliyorsunuz? Düzenlediğiniz ve gurur duyduğunuz bir şeyin örneği var mı? Çözüm bölmesinin ekran görüntüsünü paylaşabilir misiniz?

Uygulamamın UI alanında, farklı formları ve ait oldukları yerleri organize etmek için iyi bir şemaya karar vermede sorun yaşıyorum.

Düzenleme:

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

c#.netwinformscode-organization
150
Sergio

Bir proje tasarlarken ve mimariyi döşerken iki yönden başlıyorum. İlk olarak tasarlanan projeye bakıyorum ve hangi iş problemlerinin çözülmesi gerektiğini belirledim. Bunu kullanacak 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ğine ve bunları kimin kullanacağına bakıyorum.

Bir kez ne istedikleri hakkında temel bir anlayışa sahip olduğumda, temel verilerin ne olduğunu belirleyeceğim ve bu veriler için temel bir veritabanı düzenine başlayacağım. Sonra verileri çevreleyen iş kurallarını tanımlamak için sorular sormaya başlıyorum.

Her iki uçtan bağımsız olarak başlayarak, iki ucu bir araya getirecek şekilde bir proje düzenleyebiliyorum. Tasarımları bir araya getirmeden önce her zaman mümkün olduğunca uzun süre ayırmaya çalışırım, ancak ilerlerken her birinin gereksinimlerini göz önünde bulundururum.

Sorunun her bir ucunu iyi kavradığımda, sorunu çözmek için oluşturulacak projenin yapısını ortaya koymaya başlarım.

Proje çözümünün temel düzeni oluşturulduktan sonra, projenin işlevselliğine bakıyorum ve yapılan işin türüne bağlı olarak kullanılan bir ad alanları kümesi oluşturuyorum. Bu Hesap, Alışveriş Sepeti, Anketler vb.

İşte her zaman başladığım temel çözüm düzeni. Projeler daha iyi tanımlandıkça, her bir projenin özel ihtiyaçlarını karşılamak için geliştiririm. 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.
109
Amy Patterson

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ını) yanlışlıkla içe aktarmadığını garanti edebilirim. Ayrıca alt katmanlardaki katmanlarımı kırma eğilimindeyim. Yani tüm çözümlerimin bunun gibi projelerin bir listesi var:

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

Bunlar benim uygulamamın daha büyük "yapı taşları". Sonra her projenin içinde isim alanlarında daha mantıklı olarak organize ederim ama çok değişiyor. UI için çok form oluştururken, bir boşluk bölümünde düşünmeye ve sonra her "boşluk" için ad alanları oluşturmaya çalışıyorum. Diyelim ki kullanıcı denetimleri ve formları kullanıcı tercihleri ​​bir grup var, onlar için UserPreferences adında bir ad alanı olurdu, vb.

69
Alex

Proje Düzenleme

Normalde projelerimi söylediğin gibi ad alanına bölmeye çalışıyorum. Bir uygulamanın veya bileşenin her katmanı kendi projesidir. Çözümümün projelere nasıl ayrılacağına nasıl karar verdiğime gelince, bu projelerin yeniden kullanılabilirlik ve bağımlılıklar üzerine odaklanıyorum. Ekibimin diğer üyelerinin projeyi nasıl kullanacağını düşünüyorum ve yolda oluşturduğumuz diğer projeler sistemin bazı bileşenlerini kullanmaktan fayda sağlayabilir.

Örneğin, bazen, tüm çerçeve kümesine (e-posta, günlük kaydı, vb.) Sahip olan bu projeye sahip olmak yeterlidir:

MyCompany.Frameworks

Diğer zamanlarda, çerçeveleri ayrı ayrı 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 Formlar klasör çok küçük bir proje için yeterli olabilir. Bazen, tıpkı ad alanları gibi yapıları yenileyebilir ve işleri olması gerekenden daha karmaşık hale getirebilirsiniz.

  • Orta ila Büyük - Burada genellikle formlarımı işlevsel alanlara ayırmaya başlarım. Eğer bir kullanıcı yönetmek için 3 formları vardır ve benim futbol oyunları ve puanları takip tutmak bazı benim app bir parçası varsa, o zaman ben bir Formlar> Kullanıcı alan ve a = Formlar> Oyunlar alan veya bunun gibi bir şey. Gerçekten projenin geri kalanına, ne kadar ince taneli olduğum konusunda kaç şekle sahip olduğuma bağlı.

Günün sonunda, işleri daha hızlı organize etmenize ve bulmanıza yardımcı olacak ad alanlarının ve klasörlerin bulunduğunu unutmayın.

Gerçekten, bu sizin ekibinize, projelerinize ve sizin için neyin daha kolay olduğuna bağlıdır. 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 bkz --- Microsoft'un Desenler ve Uygulamaları sitesi.

19
Ryan Hayes

NET'te kod yazarken, ilgili işlevsellik kümeleri olması açık bir eğilim var. Her biri aynı alt-gruplara sahip olabilir. Ana grupları fiziksel olarak ayırmayı seviyorum - VS projesi başına bunlardan biri. Daha sonra derlemeleri kullanarak mantıksal olarak alt bölümlere ayırırım. Bu modeli takip ederek, mevcut projelerimden biri şöyle:

  • 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 seviyeleri çözmem biraz zaman aldı.

12
Grant Palin

Çözümlerinizi organize etmek için bir plana sahip olmak 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şlevlerimiz var. Proje organizasyonu yaptığımız şeye bağlıdır. Özünde:

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 istemci uygulamamız hem de bir web kullanıcı arabirimimiz varsa (sınıfta veya diğer araştırmalarda kullanım sonuçlarını toplamak için yararlıysa), ortak olarak paylaşılan koda (yani serileştirilecek veri nesneleri) sahip bir projeye ihtiyacımız vardır.

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

Gerekirse başka alt projeler de eklenebilir. Dediğim gibi, bu gerçekten projeye bağlı. Bazı projeler gerçekten basittir ve sadece temel unsurlara ihtiyaç duyar. Biz rastgele proje ayrımı ile mücadele etmeye çalışıyoruz, bu yüzden katmanlara bölmek gerçekten mantıklı. Katmanlar, projeler, çözümler arasında neyin paylaşılması gerektiği veya eklentilerin/uzantıların nelerin olması gerektiği ile tanımlanır.

7
Berin Loritsch

Pek çok insanın DRY burada düşünmemesi ilginçtir. Hayatımda birkaç kez, geliştiriciler bu nedenle inşa edilemeyen dizin yapıları oluşturdular. Proje adını koru çözüm ve proje dizinleri dışarı!

İşte benim yolum:

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

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, bunu geliştirmek için bir aşağıdan yukarıya strateji kullanırım. Her modülü geliştirdim ve sonra Onları birlikte çalıştırıyorum.

Bu modülleri, çözümüm (genellikle sınıf kütüphanelerim) altında projeler ). Her modülün farklı bir ad alanı ve kendi tasarımı vardır ( sınıflar, vb.).

Bunlardan biri modüller [~ # ~] gui [~ # ~] ( Grafik Kullanıcı Arayüzü =).

Ayrıca her zaman her projedeki değişiklikleri izlemek için bir Revizyon Denetimi aracını kullanırım. Ben öneririm Git . Açık kaynaklı, dağıtılmış ve kullanımı ücretsizdir.

2
Oscar Mederos

Yeni bir projeye her başladığımda ne yapması gerektiğine dair geniş bir özellik elde ediyorum. Bu girdiye sahip olmak bana bir bağlam sunarak bana yardımcı oluyor, bu yüzden proje hedeflerine ulaşmak için en iyi (veya en uygun) yöntemi düşünüyorum. Bu noktada, hangi desgin modellerinin amaçlanan çözümü sağlayabileceğimi düşünmeye başlıyorum. İşte proje için benimsediğim tasarım modellerini göz önünde bulundurarak projeyi düzenlemeye başladım.

Birkaç örnek:

  1. Proje yalnızca giriş veri ekranları oluşturmaya başvuruyorsa. Muhtemelen bir MVC kalıbı kullanırdım.
  2. Proje, çoklu platformları destekleyen bir ağır hizmet kullanıcı arayüzü olarak kullanılacaksa, bir MVVM tasarım modeli yardımcı olur.

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

İşte size bazı okumalar:

. Net Tasarım Desenleri .

Tasarım Desenleri .

Nesneye Dayalı Tasarım .

Bu yardımcı olur umarım.

1
El Padrino