2

I am a computer science student and while I have worked with MVC before, I have never built a project from scratch. The project is for a photography course, where the teacher will be able to upload featured photographs. The students must log in to be able to see the pictures and the assignments.

I would like for the students to log in at www.mysite.com, and the teacher at admin.mysite.com, so we have 2 different websites in one solution.

As of know my solution projects are:

  • DataLayer
  • BusinessLogicLayer
  • AdminWebsite
  • Website

Note: Gearhost is going to be my host.

Now, how will I host the AdminWebsite and the Website on two different domains, while both of them "feed" from the same BusinessLogic and DataLayer?

Should I instead make two different projects that work on the same database? Is is even possible?

I have made my research and read a bit about Areas, but I haven't been able to find a good tutorial, is it a best practice to use Areas instead, if so, can you provide me with a link to a good tutorial, or a simple example?

Thanks for reading!

rememberthecant
  • 153
  • 2
  • 9

2 Answers2

1

It is common practice for simple sites and implementation to just use one project for the public, member and admin sites.

You should be able to section each area depending on user permissions so there is no need to create two separate websites.

I would suggest the following resources for best practices and examples.

And the best place to start MVC pages at asp.net

There is also a ton of questions and community wiki entries on Stackoverflow about best practices and website layouts.

Hopes this helps

Niklas
  • 13,005
  • 23
  • 79
  • 119
dmportella
  • 4,614
  • 1
  • 27
  • 44
1

The answer is really depends. Depends of the scale of your project. You can have it all in one project (main MVC one) of you can split it further. The canonic form for this projects is something like that:

project.WEB
project.Common (here belongs common functionality between projects, so helpers, utilities, even some extension methods belong there)
project.Model (Data entities)
project.BL //(Business Logic)
project.DAL //(Data Access Layer or Persistence)
project.Tests

*note the "project" is your namespace root. How ho handle namespace naming you can check it there: namespace naming conventions

And the you can split it further and further. However I would suggest that you do not exaggerate with splitting it any further. When you will have to do it you will know (one project grow too much, there are logic separations ...). You try to follow the principle YAGNI.

And one more thing. If you want to be there "by the book" check it out DDD - Domain Driven Desing: http://msdn.microsoft.com/en-us/magazine/dd419654.aspx.

Community
  • 1
  • 1
Peter Stegnar
  • 12,615
  • 12
  • 62
  • 80
  • My answer from the closed question. That's why I copy it here: http://stackoverflow.com/questions/15267561/is-there-any-standard-approach-for-defining-projects-in-an-asp-net-mvc-solution/15267670#15267670 – Peter Stegnar Mar 09 '13 at 10:38