The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Visual Studio solution structures

Will I be able to download templates for Visual Studio solutions from the net?

I searched for solution structures in Visual Studio but I guess I'm not using the correct words.

I am working with a client where we have a project which was done by a programmer in a pretty ad hoc fashion. Everything works fine but we are trying to create a new solution and put the existing aspx, C# files in a proper structure. Are there templates available or is there a page which discusses about the way the solution can be structured and the pros and cons of a structure.

It will be good even if an image of the the structure is given for a project that's been done in a certain way.

I'm using Visual Studio 2003.
Senthilnathan N.S. Send private email
Tuesday, February 20, 2007
 
 
Do you mean "design patterns?"
Steve
Tuesday, February 20, 2007
 
 
No. I don't mean design patterns. I'm asking for something much simpler technically.

By solution structure, I mean the .sln file, which has projects inside, the one we would see if we open the Solution Explorer in Visual Studio.

Right now, the structure I'm planning to have is

slnXYZProjecct
---XYZProject.Web.DAL
---XYZProject.Web.DataHandler
---XYZProject.Web.ExceptionHandler
---XYZProject.Web.SomeModule
---
---
---

Inside each project, we have something like

---XYZSomeModule
----- + References
----- AssemblyInfo.cs
-----


Is there any way of doing this better which will make maintanence easier?
Senthilnathan N.S. Send private email
Wednesday, February 21, 2007
 
 
I think he means the physical layout of folders/files in a *.sln, or the way that code files are broken down into multiple projects within one *.sln. 

I'm afraid that's probably too broad of a question to get any meaningful answers.
Notorius L
Wednesday, February 21, 2007
 
 
Notorius L - You are correct. I mean what you think I do.
I had a feeling that I was asking something vague.

I'll be happy if someone can give the structure the way I've given above if they have used a very different one. Or refer me to a link talking about this.

Thanks in advance.
Senthilnathan N.S. Send private email
Wednesday, February 21, 2007
 
 
Most systems I have worked with has a N-Tier architecture -1. Web Layer
2. Business Layer
3. Data Layer.

Now, physically, you could break each one of them into different small projects (assemblies) as per your convenience. It depends upon various fatcors like,
1. Number of Developers
2. Source-Safe integration
3. The size of your projects

Hope you got it.
Rajeev Gopal
Wednesday, February 21, 2007
 
 
One solution and one project.

When the size of the project starts making it hard to find things, then consider breaking stuff out into separate projects.  Doing it early on just generates a lot of churn trying to figure out which project stuff was in.

That's my opinion, anyway.
Kyralessa Send private email
Wednesday, February 21, 2007
 
 
If you know it's going to be a big project (or multi-developer), it'll be worthwhile to break it up into logical groups at the front of the project.  But otherwise, just keep it in one sln.

Generally, what I've seen on larger projects is one solution/project per layer, plus one solution/project for each inter-layer transition for shared components (messaging objects, etc), plus one solution/project for objects which are truly global in scope (this would hopefully be a very small solution!)

Be sure to keep your proof-of-concept, test cases, test harnesses, etc. out of the main source directory tree.  While they're necessary, they do tend to clutter things up.  We tend to use a top-level folder structure of:

\
3rdPartyLibs
Concept
Docs
Source
Test
Tools
xampl Send private email
Wednesday, February 21, 2007
 
 
The structure we've decided on is as following
Client.Solution (vs solution file for this billable project for the client)
Client.Solution.Business
Client.Solution.Data (2 vs projects for the handling of data on this billable project)
Client.Solution.Web.Admin.UI
Client.Solution.Web.Public.UI (2 vs projects for the public and admin web sites for this billable project)

That is the naming structure for the files as well (Client.Solution.sln and Client.Solution.Web.Admin.UI.vbproj for example). The advantage of having the names as such is that it makes Namespaces default to what we would like them to be. The Web projects include references to the Business and Data layers, Business includes a ref to the Data layer.

Dunno if that's helpful to you. One word of caution, if you're on VS2005 make sure you make new web application projects, not new websites. Web Application Projects work like they did in VS2003, aka not retarded like in non-SP1 VS2005. That tip alone will save you a lot of needless frustration if you use source control and have a team of more than 1 developer.

Good luck, and I'd also like feedback on our structure if anyone has any.
tim Send private email
Wednesday, February 21, 2007
 
 
Senthilnathan,

It looks to me like you are asking for a VS2003 solution template that has all of the structure already built in for you.

If this is the case, then create the barebones solution with the references and file structure that it needs. The next step is where my memory fails me. This barebones solution then needs to get copied into a specific directory.

Here is a sort of a guide on how to do this:

http://dnnjungle.vmasanas.net/Development/Templates/tabid/28/Default.aspx?PageContentID=16

It's geared towards DotNetNuke, but you should get what you want/need from this guide.
Hector Sosa, Jr Send private email
Wednesday, February 21, 2007
 
 
Thanks for the responses.

I am with Kyralessa on the idea that we start with one solution and one project and to abstract out code as it grows. But again, it depends on the size of the project.

The project (meaning work, not the Visual Studio project) I'm currently working on is not very big. It is having many solutions and they all have one project each. I plan to put them into one solution with different projects and the common data access layer into a project and common business functions into another project.

Tim, I wanted to have a structure similar to yours. But am just doubtful if I need to separate the business layer from the UI as it wouldn't help in code reuse like the data layer would. In your structure, will you need a reference to the Data layer from the Web projects? Shouldn't it be sufficient to reference the Business layer if you are separating it?

I'm looking for a template with the structure built in as you say, Hector. I'll check the link you've referred to. Thanks.
Senthilnathan N.S. Send private email
Wednesday, February 21, 2007
 
 
"Web Application Projects work like they did in VS2003, aka not retarded like in non-SP1 VS2005. That tip alone will save you a lot of needless frustration if you use source control and have a team of more than 1 developer."

+1 to this.  I'm working with a group in a project in the "new" VS 2005 "web site" model, and it's a real pain.  If one developer deletes a file from SourceSafe, it shows up as "new" in everyone else's project, and often someone mistakenly checks it back in.
Kyralessa Send private email
Wednesday, February 21, 2007
 
 
Google Is Your Friend...

filetype:sln

http://www.google.com/search?q=filetype%3Asln

HTH/HAND
Matt Willtrout Send private email
Wednesday, February 28, 2007
 
 
I didn't think about it. That was really nice.

Thanks!
Senthilnathan N.S. Send private email
Thursday, March 01, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz