Winforms - the best directory / project structure

I wanted to see people's thoughts on the best way to organize the catalog and project structure in the project / solution for the C # winforms application.

Most people agree with the section of vision, business logic, data objects, interfaces, but want to see how different people deal with it. In addition, isolate third-party dependencies in implementation projects, and then export projects that users reference

View.csproj BusinessLogic.csproj Data.csproj CalculatorService.Exported.csproj (interfaces) CalculatorService.MyCalcImpl.csproj (one implementation) CalculatorService.MyCalcImpl2.csproj (other implementation)

In addition, with regard to the folder structure, what is better than nesting:

Interfaces
--- IFoo
--- IDATA
Impl
--- Foo
--- Data

or


Product --- Interfaces / IProduct
--- Impl /
product foo
--- Impl / Foo
--- Interfaces / IFoo

All attempts to click for unleashed dependencies on abstractions and the quick possibility of changing implementations.

Thoughts? Best practics?

+6
c # winforms
source share
3 answers

For me, it depends on the model I am sticking to. If I use MVC, it will be

Project -Models -Controllers -Views 

Or for MVP it will be

 Project -Models -Presenters -Views 

Under the views, I divide them into namespaces related to controllers, i.e. if I have a controller to handle inventory transactions, I could have it as

 Project -Models --Inventory -Controllers --Inventory ---TransactionsController.cs -Views --Inventory ---Transactions ----EditTransactionsView.dfm 

For interfaces, I put the interface in the same directory as the implementations.

+6
source share

A little late reply, but may also call back.

I personally used folders based on the actual type of the item. For example:

 - Project + Forms + Classes + UserControls + Resources + Data 

So, I get:

 new Forms.AboutForm().ShowDialog(); Controls.Add(new Controls.UberTextBox()); 
+4
source share

We usually save SourceSafe projects, project names, namespaces, and directory structures.

For example, given our company name as XCENT, the SourceSafe structure and the corresponding directory structure for App1 is as follows:

 \XCENT \XCENT\App1 \XCENT\App1\UI \XCENT\App1\UI\Test //test harness for UI \XCENT\App1\Data \XCENT\App1\Data\Test //test harnesses for Data 

and etc.

The UI project is called XCENT.App1.UI.cproj, and the classes in this namespace are called XCENT.App1.UI

We work for many clients, so work specially for them has a prefix with their name. Client1 \ App1 \ UI, etc.

Everyone in our company uses the same agreements, and it immediately becomes clear where everything fits.

If it makes sense to segment the logical distance, we do it. Such other segmentation includes .Export, .Import, .Reporting, .Security, etc.

0
source share

All Articles