views:

58

answers:

1

I'm developing MVC application where I currently have 3 projects in solution.

  • Core (it is supposed to be for Repositories, Business Classes, Models, HttpModules, HttpFilters, Settings, etc.)
  • Data access (Data provider, for instance SqlDataProvider for working with SQL Server datastore - implements Repository interfaces, XmlDataProvider - also implements Repository interfaces but for local XML files as datastore)
  • ASP.NET MVC project (all the typical stuff, UI, controllers, content, scripts, resources and helpers).

I have no Models in my ASP.NET MVC project. I've just run into a problem because of that coz I want to use the new DataAnnotation feature in MVC 2 on my Business class, which are, as said in Core, however I want to be able to localize the error messages. This where my problem starts. I cannot use my Resources from MVC project in Core. The MVC project references Core and it cannot be vice-versa.

My options as I see them are: 1) Move Resources out but this would require correcting a whole bunch of Views and Controllers where I reference them, 2) Make a complete restructure of my app

What are your thoughts on this? Also, Should I just move everything business related into Models folder in MVC project?? Does it even make any sense to have it structured like that, because we can just make subfolders for everything under MVC project? The whole Core library is not intended to ever be used for anything else, so there actually no point of compiling it to a separate DLL.

Suggestions appreciated.

+2  A: 

Throw it all into one big .csproj boat and use folders to separate things. Its much easier to navigate folders than separate projects. You won't have to fight namespaces all the time and everything is right were you expect it. You completely eliminate any .sln kung fu when things aren't int he right location or assemblies need to be referenced and you can spend more time coding rather than moving .sln bits around.

Some people say it makes it harder to "swap out an implementation" which is baloney. Swapping the contents of a folder is just as easy as swapping the project.

The MVC source is what made me fond of this approach. They flatten everything out and its really easy to swim around their source code.

jfar
nice answer really!
mare
The advantage of breaking things apart is when you make a change you don't have to recompile everything, just the project that changed. You don't really see this advantage until you start unit testing. When you're TDD-ing a domain class do you really want to keep rebuilding all your HTTP modules, DBML, and web project? (Also, I always keep my dbml in it's own project because it's typically about 2/3 of my total build time.)Another thing I do is have an MVC project w/ just the views in it. Keep all the controllers, filters, global.asax.cs, etc in a separate class library project.
Ryan