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.
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.
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:
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.
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
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.
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:
Umarım bu sizin için yararlıdır. Ayrılma seviyeleri çözmem biraz zaman aldı.
Çö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.
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
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ü =).
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:
Bunların her birinin sizi projenizi belirli bir şekilde düzenlemeye zorlayacağını unutmayın.
İşte size bazı okumalar:
Bu yardımcı olur umarım.