3

Possible Duplicate:
Namespace/solution structure

If I am creating a large C# app, should I keep it all in one project?

I plan on having a data layer and GUI layer. Should these be in one project or should they be split up into two projects? At this stage I think it should all be in one project, because you can just have a separate folder of classes that represent the data layer and instantiate them when needed.

Let's say I had a separate project for the data layer, what should this project (and therefore the DLL) be called? I am not going to call it <ProductName>_DataLayer.DLL. You never see that.

Are there any other important issues? Is it important to keep the size of the main .EXE down?

Community
  • 1
  • 1
CJ7
  • 22,579
  • 65
  • 193
  • 321

7 Answers7

2

My personal favorites on the topic: Scott Hanselman, Mike Roberts

kol
  • 27,881
  • 12
  • 83
  • 120
1

You should make these layers as separated projects inside the same solution for example the data layer would be a Class Library project and it might be named YourProjectName.DAL for example ProductName.DAL.DLL or DataLayer

Mahmoud Gamal
  • 78,257
  • 17
  • 139
  • 164
0

Data and GUI separation is always recommended, you never know what you'll need to do with the data layer in future.

I'm using the .Data .UI naming conventions, and it's fine.

Chen Kinnrot
  • 20,609
  • 17
  • 79
  • 141
0

I would definitely keep separate layers in their own projects. Depending on the size of the application, I would also recommend looking at breaking it down further into logical groupings based on functionality.

You can call it whatever you want. You can set the assembly name to be different than the project name in the Properties window of the project.

Tim
  • 28,212
  • 8
  • 63
  • 76
0

The consideration you have to make is whether you want to reuse the datalayer between multiple projects. If the answer is yes then you should put it in a separate project.

If no, it might still be wise to separate it from the GUI simply just in case a scenario comes up you didn't think of. (e.g. you decide to create a webservice)

Naming: I prefer DATA and UI for naming conventions.

If the solution becomes really big, you can consider using 'solution folders'.

Peter
  • 14,221
  • 15
  • 70
  • 110
0

The more simpler way is to have all projects in the same solution.

But if you have a lot of project - the projects which were created a long time ago and are not modified (or modification is vary rare) - is better to exclude them from solution, move DLL's to some common folder and use as dll references from the solution.

For name we're using dot separated - for example <project>.dal.dll

Vitaliy
  • 2,744
  • 1
  • 24
  • 39
0

Different projects within the same solution is a good way to do it, but really depends on how the project will be used.

At one point it was common to have a ProjectName.UI > ProjectName.BLL > ProjectName.DAL architecture, then create a Model project to define data contracts to move data between the layers.

BLL = Business Logic Layer DAL = Data Access Layer

Each layer is compiled into different assemblies, with an EXE for your interface. The size of your compiled EXE isn't really a concern, but more getting the architecture right - if you have a separate project for each layer it will make your deployment more manageable.

Now it is more common to use the Repository pattern architecture, which lends itself well to using ORMs. It you want testable, component based code that is easy to develop and refactor you should definitely look into using repositories.

alundy
  • 857
  • 8
  • 22
  • 1
    ;) Sticking to the .NET pattern i use .Presentation for the UI, .Persistence for the data layer and .Logic for the logic. – TomTom Nov 21 '11 at 09:21