Website Structure Planning

Question

User1064403333 posted

Hi, previously, I always created ASP.NET Web Forms where everything is in a single Web Site.

http://www.example.com/
http://www.example.com/images
http://www.example.com/subfolder1
http://www.example.com/subfolder2

Over time, the number of folders just grew, and kept growing where a minor change to an ASPX page requires me to rebuild and upload the entire site (because I used the Pre-Compiled technique).

Also, I would have the BLL and DAL in the App_Code folder.

For a new web site I’m thinking there must be a better way and I’m seeking advice from developers that have coded large scale sites.

In terms of web site structure planning, I am considering:

http://www.example.com/
http://images.example.com/
http://subdomain1.example.com/
http://subdomain2.example.com/

Should I individually separate all the main components i.e. the

• BLL
• DAL
• the main site
• images site
• each subdomain

into their own Project under one Solution?

What are the negative aspects to this approach?

Thanks

Answer 1

User1291589676 posted

First create a blank solution and then add you BLL & DAL applications as type class library and then add new project for each you website as type web application.

In your each webapplication add reference to BLL and DAL.

Note: Don't Create Website instead create as Web Application.

In web application you can call any function of reference dll from anywhere in your application.

Answer 2

User1064403333 posted

Thanks Prabu

First create a blank solution and then add you BLL & DAL applications as type class library

Cool, the blank solution sounds like a clean start.

Do you mean Windows Class Library project type?

Should the BLL be a seperate class library to DAL, or should they be together in the same class library, or it makes no difference?

Note: Don't Create Website instead create as Web Application.

Why? Please elaborate if you can ...

Website now has the same publishing process as Web Application. Are there other reasons?

In web application you can call any function of reference dll from anywhere in your application.

I plan to use MVC 4 for some of the above subdomains and Web Forms for others. Can I still use the above reference strategy?

Also, how do I programmatically reference static content such as images now.

Previously I would use the "~/images/". I guess I replace that with the full URL e.g. http://images.example.com/images/file.jpeg but I do not know if I have programmatic control such as HttpHandler and Module from http://subdomain1.example.com/ ???

Thanks

 

Answer 3

User-1002157272 posted

The business layer doesn't technically HAVE to be in a seperate lib from the data access layer, however if you want it to be pluggable (modularized) then yes they should be in seperate libs. If there are shared common types between the two and you want seperate assemblies for bll and dal, create an additional lib that defines the common types and reference it in both.

Website may deploy similar to web app now but structurally they are night and day. websites are still a file structure and web applications are precompiled assemblies.

If you plan to use mvc 4, you could use custom routing configurations to emulate subdomains super easily. Seriously, I have been able to do some pretty crazy things with custom routing configurations. MVC also has a feature called "Areas" which sort of internally represent subdomains, but I would suggest doing your homework on areas first before getting too deep in them as they are rather finicky in some ways.

Image links would be the same thing. You would supply the relative path to the html helper and bam, does it for you when it resolves it at runtime. And yes, you can still use custom handlers and modules in mvc, however, you may wanna look into custom filters instead.