Application structure - what do you do?
-
So, I just listened to podcast #6 from stackoverflow.com and I was amazed when Joel Spolsky described how he structures his own ASP.NET applications. Not that there's anything wrong with it but it was just very different than how I do it. He said that usually he has few pages and then a big switch that switches on verbs in the request address. The various case statements then makes a user control visible which then handles the actual action. Personally I just like to have many very small pages with small responsibilities (obviously I´m mainly talking about actual web applications and not web sites) since I like it clean and lean. Anyway this made me curious as how different people structure their ASP.NET apps. So how do you do it?
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn Rand -
So, I just listened to podcast #6 from stackoverflow.com and I was amazed when Joel Spolsky described how he structures his own ASP.NET applications. Not that there's anything wrong with it but it was just very different than how I do it. He said that usually he has few pages and then a big switch that switches on verbs in the request address. The various case statements then makes a user control visible which then handles the actual action. Personally I just like to have many very small pages with small responsibilities (obviously I´m mainly talking about actual web applications and not web sites) since I like it clean and lean. Anyway this made me curious as how different people structure their ASP.NET apps. So how do you do it?
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn Rand -
So, I just listened to podcast #6 from stackoverflow.com and I was amazed when Joel Spolsky described how he structures his own ASP.NET applications. Not that there's anything wrong with it but it was just very different than how I do it. He said that usually he has few pages and then a big switch that switches on verbs in the request address. The various case statements then makes a user control visible which then handles the actual action. Personally I just like to have many very small pages with small responsibilities (obviously I´m mainly talking about actual web applications and not web sites) since I like it clean and lean. Anyway this made me curious as how different people structure their ASP.NET apps. So how do you do it?
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandRohde wrote:
I just listened to podcast #6 from stackoverflow.com
Good one. I was not aware of this. Thanks for posting :)
Rohde wrote:
Anyway this made me curious as how different people structure their ASP.NET apps. So how do you do it?
I used to consider easy maintainability while designing application. Business objects and data objects will be in separate projects. Business objects will be loosely coupled which helps to test the code easily. It also helps to improve portability and not depended with ASP.NET. I used to do dependency injection kind of design for the business objects, so that Data access objects can be easily mocked while testing. I too create many ASPX pages. If any user interfaces are repeating in more than one page, I used to wrap it in custom controls.
All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions
-
Rohde wrote:
I just listened to podcast #6 from stackoverflow.com
Good one. I was not aware of this. Thanks for posting :)
Rohde wrote:
Anyway this made me curious as how different people structure their ASP.NET apps. So how do you do it?
I used to consider easy maintainability while designing application. Business objects and data objects will be in separate projects. Business objects will be loosely coupled which helps to test the code easily. It also helps to improve portability and not depended with ASP.NET. I used to do dependency injection kind of design for the business objects, so that Data access objects can be easily mocked while testing. I too create many ASPX pages. If any user interfaces are repeating in more than one page, I used to wrap it in custom controls.
All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions
N a v a n e e t h wrote:
Good one. I was not aware of this. Thanks for posting [Smile]
Well, basically Joel Spolsky and Jeff Atwood (from codinghorror.com) are collaborating on creating stackoverflow.com which is to be some sort of developer resource, wiki, question/answer digg-kind of thing. And so far they have recorded 6 podcasts wherein they discuss their idea about stackoverflow and various technical programming issues as well. Pretty interesting stuff.
N a v a n e e t h wrote:
I used to consider easy maintainability while designing application. Business objects and data objects will be in separate projects. Business objects will be loosely coupled which helps to test the code easily. It also helps to improve portability and not depended with ASP.NET. I used to do dependency injection kind of design for the business objects, so that Data access objects can be easily mocked while testing.
Yeah that's pretty much as I do as well. Although I haven't used DI too much; but I'm migrating towards it.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn Rand -
Rohde wrote:
I just listened to podcast #6 from stackoverflow.com
Good one. I was not aware of this. Thanks for posting :)
Rohde wrote:
Anyway this made me curious as how different people structure their ASP.NET apps. So how do you do it?
I used to consider easy maintainability while designing application. Business objects and data objects will be in separate projects. Business objects will be loosely coupled which helps to test the code easily. It also helps to improve portability and not depended with ASP.NET. I used to do dependency injection kind of design for the business objects, so that Data access objects can be easily mocked while testing. I too create many ASPX pages. If any user interfaces are repeating in more than one page, I used to wrap it in custom controls.
All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions
I know people probably won't agree with me... But I only separate data / business rules / presentation if I know that I will need to use the code elsewhere. I am fully aware of how to create classes that represent objects in my database. I also know how to use a generic list (of those objects) as a datasource. That being said I often write stored procedures to be used only in one web page and just use a datareader right in the code behind. It is quicker to write, easy to debug / modify and just simpler. I have been programming asp.net for the last 7 years and I went through a phase where I would "architect" everything. But then I found that I would end up with more bugs and have a tougher time "jumping back into the code" if a major change was requested. So now I try not to architect too much and just keep it simple. Just my two cents. I also use lots of user controls and web pages. I try not to clutter up my aspx pages with too many controls...
I didn't get any requirements for the signature
-
I know people probably won't agree with me... But I only separate data / business rules / presentation if I know that I will need to use the code elsewhere. I am fully aware of how to create classes that represent objects in my database. I also know how to use a generic list (of those objects) as a datasource. That being said I often write stored procedures to be used only in one web page and just use a datareader right in the code behind. It is quicker to write, easy to debug / modify and just simpler. I have been programming asp.net for the last 7 years and I went through a phase where I would "architect" everything. But then I found that I would end up with more bugs and have a tougher time "jumping back into the code" if a major change was requested. So now I try not to architect too much and just keep it simple. Just my two cents. I also use lots of user controls and web pages. I try not to clutter up my aspx pages with too many controls...
I didn't get any requirements for the signature
ToddHileHoffer wrote:
But then I found that I would end up with more bugs and have a tougher time "jumping back into the code" if a major change was requested. So now I try not to architect too much and just keep it simple.
I can't agree fully. AFAIK, if you have automated unit test cases, you can do this more easily. You can easily find out the areas which are breaking. Right ?
All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions
-
ToddHileHoffer wrote:
But then I found that I would end up with more bugs and have a tougher time "jumping back into the code" if a major change was requested. So now I try not to architect too much and just keep it simple.
I can't agree fully. AFAIK, if you have automated unit test cases, you can do this more easily. You can easily find out the areas which are breaking. Right ?
All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions
Well, I never did any "unit test cases". Its not like my code was broken just the occasional object reference not set...
I didn't get any requirements for the signature