Separating projects

[imaginekitty]

In the past I've separated my MVC solutions into separate projects. Domain, WebUI, Persistence, etc.

Is there any reason for that if I'm just writing for myself and I'm the only programmer?

Why not just contain everything in one project using the standard MVC folder layout?

[NightStalker-DNS]

Well, it comes down to preference. If you sure you do not need it, you do not have to do it. But I tend keep it in layers. So that in the future, if for some reason, I decide to to a mobile version of my site for example, I can just include my persistance and domain project references and would not have to copy paste all the code.

[wwb_99]

Only hard and fast rule is separating the core logic / peristance stuff from the UI layer. You never know when you need to make a command line interface to your web project's data.

[imaginekitty]

Only hard and fast rule is separating the core logic / peristance stuff from the UI layer. You never know when you need to make a command line interface to your web project's data.

It is a good point. I'm making a mobile web app and I suppose I can eventually make a native app in the future. I probably never will but at least the option is there.

[Serenarules]

I find that separating the concerns into projects of their own an aide to my own thinking processes. It helps me conceptualize and visualize a layers actual responsibilities. In your case, there is a third option. Simply branch the Models namespace into Models/Domain, Models/Persistence, and Models/Presentation. Later, if you decide to pull these out into their own projects, name them MyProject.Models.Domain, MyProject.Models.Persistence and MyProject.Models.Presentation and they'll continue to work with their given namespaces, as long as you add cross project references.

=)

Sometimes people only see the black and white solutions, overlooking the grey, when grey is the color being sought.

[imaginekitty]

I find that separating the concerns into projects of their own an aide to my own thinking processes. It helps me conceptualize and visualize a layers actual responsibilities. In your case, there is a third option. Simply branch the Models namespace into Models/Domain, Models/Persistence, and Models/Presentation. Later, if you decide to pull these out into their own projects, name them MyProject.Models.Domain, MyProject.Models.Persistence and MyProject.Models.Presentation and they'll continue to work with their given namespaces, as long as you add cross project references.

=)

Sometimes people only see the black and white solutions, overlooking the grey, when grey is the color being sought.

Sounds good!

Gray is the new blackandwhite.

[Alex69]

If you are 100% sure that it will remain your internal project, and it will remain small, and there are not expected many changes in future, then it will be faster to develop all this in one project. But if you are not sure, then dividing into layers will take you some more time now, but save very much time in future, when you want to make some significant changes.

By the way, you can divide your application into layers within one project too - just have different classes for Domain, UI, DataAccess etc, and put them to different folders so that to differ them easier.

[Serenarules]

One thing I'd like to point out as a feather in the hat for separation is the ease of maintenance and deployability. It is far easier to deploy a smaller, single file named FooBarApp.Persistence.Impl.dll and have the user drop it in their bin folder than it is to redeploy an entire solution.