views:

42

answers:

2

I am in the beginning stages of creating an asp.net solution with 3 very different areas. I will have a client area, a client admin area, and an internal admin area. Each one of these areas is significantly different and there would be not be overlap in functionality. I was thinking of structuring the solution as follows:

  • Client (Project)
  • Client Admin (Project)
  • Internal (Project)
  • Generic Library (Project) to hold shared tasks.

Is this an accurate way to structure the solution? Are there pitfalls that I might run into with this? How would the session state (sql) work across the projects if I wanted to access some user data between projects?

Thank you for your help.

A: 

Your project structure looks fine.

As far as session state goes, you can deploy your three web projects under the umbrella of one application.

Larsenal
So as long as the projects are deployed under the same IIS application then it will be able to share the session state?
Evan
I cannot think of anything that you will not be able to counter with "You should store that in the database" or "That is not the way you should do it". Unfortunately I am working on a system that I am attempting to rewrite and the legacy system will need to interact with it. Currently they are holding user and state related data, which is different to get away from in one swoop.
Evan
A: 

Why not keep the projects together as one? I have seen on several projects where the "Internal" project will get neglected or excluded from the build during a difficult refactoring.

SargeATM
I would like to keep all of these in the same solution, but as different projects due to the large difference in functionality between the projects that cannot be abstrated away. I am worried about new code being able to integrate with a legacy project.
Evan