What is a good design for a web application?
Experts, I would really like your inputs on this issue that has been nagging me whenever I try to design a good architecture for a web application..
I would really like your inputs on how to apply design patterns like MVC on a web application. I have read articles and links which explain the patterns as such. Most of these consider the scenarios where the development is for a windows application or where the approach is very OO that it might not be very practical when the design is for a web project (not a product) where the environment is more controlled and tightly coupled. Taking the case of a MVC pattern, its pretty well implemented in the ASP.net projects where the aspx page is the view, the code behind page is the controller and the business layer + data layer is the model. Do correct me if I am wrong here .. So basically it looks just like a n-tiered architecture or am I missing anything?
I would like to separate each of these blocks and have definte rules set for each of them. For eg, I would prefer that the model never interacts with any of the HTTPcontext or UI objects. But then I had some issues when I was planning to implement caching/sessions etc. Would my business layer never refer to cache objects? If not, does it make sense to pass all these values as parameters to methods defined in business layer? What happens when you run into a situation like a master-detail screen where the all the records needs to be updated with a transaction. So if you plan to hold on to the information in the session till the user commits, will the code to store and retrive values from the session be written in the business or UI layer?
Now that SP have become really very powerful, most of the business logic can be implemented on the database design or in stored procedures. Now that even XML data types are supported by SQL server, transaction is also not an issue and all the records that need to be updated in a transaction can be send in one database connection as a XML and the stored procedure can handle the transaction. So what exactly will you use business layer for?
Please provide your inputs or any links that I can read to get a more practical explantion of all these scenarios .. I would love to hear about your experience in designing web application and your approach in tackling these issues ..
Do have a look at this link. It started well and looked interesting, but it is not complete ..
Design Patterns in Web Programming
http://www.e-gineer.com/v1/articles/design-patterns-in-web-programming.htm
another one ..
Improving the design pattern of web applications with AJAX
http://www.codeproject.com/useritems/AJAX_MVC.asp
Thanks a lot in advance
Rejo
I would really like your inputs on how to apply design patterns like MVC on a web application. I have read articles and links which explain the patterns as such. Most of these consider the scenarios where the development is for a windows application or where the approach is very OO that it might not be very practical when the design is for a web project (not a product) where the environment is more controlled and tightly coupled. Taking the case of a MVC pattern, its pretty well implemented in the ASP.net projects where the aspx page is the view, the code behind page is the controller and the business layer + data layer is the model. Do correct me if I am wrong here .. So basically it looks just like a n-tiered architecture or am I missing anything?
I would like to separate each of these blocks and have definte rules set for each of them. For eg, I would prefer that the model never interacts with any of the HTTPcontext or UI objects. But then I had some issues when I was planning to implement caching/sessions etc. Would my business layer never refer to cache objects? If not, does it make sense to pass all these values as parameters to methods defined in business layer? What happens when you run into a situation like a master-detail screen where the all the records needs to be updated with a transaction. So if you plan to hold on to the information in the session till the user commits, will the code to store and retrive values from the session be written in the business or UI layer?
Now that SP have become really very powerful, most of the business logic can be implemented on the database design or in stored procedures. Now that even XML data types are supported by SQL server, transaction is also not an issue and all the records that need to be updated in a transaction can be send in one database connection as a XML and the stored procedure can handle the transaction. So what exactly will you use business layer for?
Please provide your inputs or any links that I can read to get a more practical explantion of all these scenarios .. I would love to hear about your experience in designing web application and your approach in tackling these issues ..
Do have a look at this link. It started well and looked interesting, but it is not complete ..
Design Patterns in Web Programming
http://www.e-gineer.com/v1/articles/design-patterns-in-web-programming.htm
another one ..
Improving the design pattern of web applications with AJAX
http://www.codeproject.com/useritems/AJAX_MVC.asp
Thanks a lot in advance
Rejo
Rejo,
Here's my two cents, well OK, maybe three cents.
I think we should keep in mind that not all applications are the same and they all call for different designs, so no one can give you a one-size-fits-all solution. That said, the majority of time I will stick with a basic multi-layered object-oriented design and then tweak it as the need arises.
I always start with a model that represents the business entities, these would be business objects and services. I would then create a data store whose design is best for storing the data of the business. I then would create a Data Access Layer that bridges the gap between the data store design and my business design. I also would create an infrastructure layer that sits with the business model to handle things like security, logging, and datamapping (data returned from Data Access Layer and Mapping it to Business Objects. I also would have a testing layer full of classes that make sure my business services and objects do what the business experts say they should.
At this point, my application is complete. I know it works. It is ready to be used by any client that needs to interact with whatever domain it is representing. So what kind of clients would that be, maybe a Service running on a server, maybe a phone system, maybe a GUI like a Windows front end, or maybe like in your case, a Web front end.
In this case of a web front end I may add another layer of what is commonly referred to as controller objects to sit between the web code and the business layer code. This is because the web front end is disconnected and may need serialization and singe calls that do 5 things, etc. I don't want to corrupt my business layer with user interface concerns, so this extra layer is created.
When it comes to ASP.Net the code-behind classes would talk ot the controller to get or set whatever it needed via a call to the controller. All user interface and specific web UI stuff like sessions, etc has nothing to do with whatever business I am working in (accounting, quiz management, store-front, etc) thus these things are not mixed up with the business concepts. Just like I think you said "For eg, I would prefer that the model never interacts with any of the HTTPcontext or UI objects"
If you would like we could talk through a specific requirement, or functionality and how that might work. Right now I am working on an application for a finance company that collects enrollment elections for people participating in a retirement plan. The application does have a web front end that needs to collect info on how much they want to defer (20% of their salary, etc) how they want their deferred money invested (20% in Microsoft, 80% in GE, etc) and how they want to be paid when they retire (Lump Sum or maybe annual installment, etc).
Notice I refrain from calling the application a web application. To me it is a nuance, but I think it is very important. I am building an application that has a web front end. There is nothing web-ish about my application except that you can gain access to it via the web. However, nothing about the application changes when you access it via the phone (please press 2 to choose Lump Sum) or via a Windows front end.
OK, so maybe that was 5 or 6 cents!
-Cheers,
Joe
Here's my two cents, well OK, maybe three cents.
I think we should keep in mind that not all applications are the same and they all call for different designs, so no one can give you a one-size-fits-all solution. That said, the majority of time I will stick with a basic multi-layered object-oriented design and then tweak it as the need arises.
I always start with a model that represents the business entities, these would be business objects and services. I would then create a data store whose design is best for storing the data of the business. I then would create a Data Access Layer that bridges the gap between the data store design and my business design. I also would create an infrastructure layer that sits with the business model to handle things like security, logging, and datamapping (data returned from Data Access Layer and Mapping it to Business Objects. I also would have a testing layer full of classes that make sure my business services and objects do what the business experts say they should.
At this point, my application is complete. I know it works. It is ready to be used by any client that needs to interact with whatever domain it is representing. So what kind of clients would that be, maybe a Service running on a server, maybe a phone system, maybe a GUI like a Windows front end, or maybe like in your case, a Web front end.
In this case of a web front end I may add another layer of what is commonly referred to as controller objects to sit between the web code and the business layer code. This is because the web front end is disconnected and may need serialization and singe calls that do 5 things, etc. I don't want to corrupt my business layer with user interface concerns, so this extra layer is created.
When it comes to ASP.Net the code-behind classes would talk ot the controller to get or set whatever it needed via a call to the controller. All user interface and specific web UI stuff like sessions, etc has nothing to do with whatever business I am working in (accounting, quiz management, store-front, etc) thus these things are not mixed up with the business concepts. Just like I think you said "For eg, I would prefer that the model never interacts with any of the HTTPcontext or UI objects"
If you would like we could talk through a specific requirement, or functionality and how that might work. Right now I am working on an application for a finance company that collects enrollment elections for people participating in a retirement plan. The application does have a web front end that needs to collect info on how much they want to defer (20% of their salary, etc) how they want their deferred money invested (20% in Microsoft, 80% in GE, etc) and how they want to be paid when they retire (Lump Sum or maybe annual installment, etc).
Notice I refrain from calling the application a web application. To me it is a nuance, but I think it is very important. I am building an application that has a web front end. There is nothing web-ish about my application except that you can gain access to it via the web. However, nothing about the application changes when you access it via the phone (please press 2 to choose Lump Sum) or via a Windows front end.
OK, so maybe that was 5 or 6 cents!
-Cheers,
Joe
ASKER
thanks Joe for 6 cents worth .. i really appreciate it ..
What you mention is correct that there is not one-size-fit-all solution .. what i was looking for is when the environment is pretty tightly coupled .. so the front end is always web .. what you have mentioned fits very well to most of the examples that most of the books mention where you design a application which serves all types of UI or which runs in any environment etc etc .. but in my practical experience I have not seen too many projects that had similar requirements and even if they had all them had to be customised to suit different environment .. I used to work for a company that build the world's currently number one financial banking solution .. Oracle had purchased that organization last year .. even though I was not part of the team that build it, I had heard a lot of stories from my team mates who used to customisize that product for different clients who had diverse enviroments ..
anyway, maybe what I am trying to find out is whether all those layers are really required when the environment is pretty well known and controlled .. isn't it just making the baggage heavy and that much less scalable? in your example where are you using the features that a web front end would supports like sessions, caching etc? if those are in the controller or the code behind how are those objects been stored .. take an example that I have mentioned above .. what if you want to cache objects with country and state information .. would they be stored in the cache as a datatable or objects created from your business layers? if they are objects, again are you not loosing on a lot of functionality like search, rowfilter etc that a datatable supports. You will have build all those rules on your web application/controller .. wouldn't that make the code more "thick" or isn't that what your business logic is supposed to handle?
Rejo
What you mention is correct that there is not one-size-fit-all solution .. what i was looking for is when the environment is pretty tightly coupled .. so the front end is always web .. what you have mentioned fits very well to most of the examples that most of the books mention where you design a application which serves all types of UI or which runs in any environment etc etc .. but in my practical experience I have not seen too many projects that had similar requirements and even if they had all them had to be customised to suit different environment .. I used to work for a company that build the world's currently number one financial banking solution .. Oracle had purchased that organization last year .. even though I was not part of the team that build it, I had heard a lot of stories from my team mates who used to customisize that product for different clients who had diverse enviroments ..
anyway, maybe what I am trying to find out is whether all those layers are really required when the environment is pretty well known and controlled .. isn't it just making the baggage heavy and that much less scalable? in your example where are you using the features that a web front end would supports like sessions, caching etc? if those are in the controller or the code behind how are those objects been stored .. take an example that I have mentioned above .. what if you want to cache objects with country and state information .. would they be stored in the cache as a datatable or objects created from your business layers? if they are objects, again are you not loosing on a lot of functionality like search, rowfilter etc that a datatable supports. You will have build all those rules on your web application/controller .. wouldn't that make the code more "thick" or isn't that what your business logic is supposed to handle?
Rejo
ASKER
Joe, any comments?
"so the front end is always web " What kind of web, it always be a web service? It will always be a plain HTML front end? It will always be ASP.Net? It will always be an AJAX enabled front end? Will you not upgrade to the newest Microsoft technology following ASP.Net?
I will tell you that that everything changes.
So my point is, maybe your application will only ever be accessed from a web front end. However, what that front end looks like will be very different. Maybe you will upgrade to ASP.Net 4.0 in 5 years, maybe you'll want to switch to C#, or D%, or some other new language. Maybe you will want to start using AJAX. These are still changes to the "web" front end but they sure have nothing to do with the business. Will your switch be easy, or will it be such a pain that you'll never be able to do it?
Now, to me, this separation of concerns allows you to use the same application with different front ends. That might be switching from ASP.Net to a Windows UI or switching from ASP.Net to .Net 4.0 with AJAX. However, this is just a bonus to the real benefit of a separation of concerns into logical and physical tiers. The real benefit is simply a separation of concerns. Writing software is hard enough, and learning new business that we write software to model is harder still. My best weapon against the natural complexities of the convergence of software and business is to divide and conquer.
What that means is that I (and the code I am writing) only want to deal with one thing at a time, only want to be concerned with one thing at a time. In order to do this we need a separation of those concerns. That means when I am working on the user interface, I am only working on UI stuff, it is not tangled like spaghetti with business stuff, or security issues, or logging issues, or database issues, etc. The same goes for the rest. If I am working on the database stuff I don't want to be concerned with user interface stuff.
My brain is just not that big. Furthermore, I am a pretty good tester and I want to be able to test my logging stuff separate from my UI stuff, and my database stuff separate from my business stuff, etc, etc.
<<that much less scalable>>
Furthermore, some would argue the best benefit of layers IS scalability. (every one has there own reasons, but I think they are all valid in their own right). Imagine your application, that I know will never change, needs to scale. Let's say you used an Access backend, but now you need something bigger, like SQL server. If you have separated your concerns then the UI and business code do not change, you only change your data access layer. If anything goes wrong, you know immediately where the problem lies. Let's say you pick up C# and would like to scale up to a more powerful server to handle some complex transactions that are taking too long with all the new web traffic. This change should be able to be made with absolutely no affect on your user interface or database code. You would only be concerned with moving the business code to a new powerful server and new language.
I'm not sure exactly what you are asking in regards to "sessions, cache, countries, sorting, etc". I do use ASP.Net's session object to hold the state of things between page loads if that is what you are asking. If I needed a list of countries I would probably ask for the list of countries that would ultimately come from the database.
-Joe
I will tell you that that everything changes.
So my point is, maybe your application will only ever be accessed from a web front end. However, what that front end looks like will be very different. Maybe you will upgrade to ASP.Net 4.0 in 5 years, maybe you'll want to switch to C#, or D%, or some other new language. Maybe you will want to start using AJAX. These are still changes to the "web" front end but they sure have nothing to do with the business. Will your switch be easy, or will it be such a pain that you'll never be able to do it?
Now, to me, this separation of concerns allows you to use the same application with different front ends. That might be switching from ASP.Net to a Windows UI or switching from ASP.Net to .Net 4.0 with AJAX. However, this is just a bonus to the real benefit of a separation of concerns into logical and physical tiers. The real benefit is simply a separation of concerns. Writing software is hard enough, and learning new business that we write software to model is harder still. My best weapon against the natural complexities of the convergence of software and business is to divide and conquer.
What that means is that I (and the code I am writing) only want to deal with one thing at a time, only want to be concerned with one thing at a time. In order to do this we need a separation of those concerns. That means when I am working on the user interface, I am only working on UI stuff, it is not tangled like spaghetti with business stuff, or security issues, or logging issues, or database issues, etc. The same goes for the rest. If I am working on the database stuff I don't want to be concerned with user interface stuff.
My brain is just not that big. Furthermore, I am a pretty good tester and I want to be able to test my logging stuff separate from my UI stuff, and my database stuff separate from my business stuff, etc, etc.
<<that much less scalable>>
Furthermore, some would argue the best benefit of layers IS scalability. (every one has there own reasons, but I think they are all valid in their own right). Imagine your application, that I know will never change, needs to scale. Let's say you used an Access backend, but now you need something bigger, like SQL server. If you have separated your concerns then the UI and business code do not change, you only change your data access layer. If anything goes wrong, you know immediately where the problem lies. Let's say you pick up C# and would like to scale up to a more powerful server to handle some complex transactions that are taking too long with all the new web traffic. This change should be able to be made with absolutely no affect on your user interface or database code. You would only be concerned with moving the business code to a new powerful server and new language.
I'm not sure exactly what you are asking in regards to "sessions, cache, countries, sorting, etc". I do use ASP.Net's session object to hold the state of things between page loads if that is what you are asking. If I needed a list of countries I would probably ask for the list of countries that would ultimately come from the database.
-Joe
ASKER
hmm .. thx .. I am not too convinced and maybe I am not asking the right questions ..
>>Maybe you will upgrade to ASP.Net 4.0 in 5 years, maybe you'll want to switch to C#, or D%, or some other new language. Maybe you will want to start using AJAX.
Yes, changes are inevitable. But should you be deisgning your application solely for changes that you are not even aware of? Any good design will be looking at business requirements and not trying to design a application which will support furture software changes .. atleast I have found that to like "trying to shoot a moving target" .. I have seen application which remain the same way without changes just because changes are too expensive (Y2K was a classic example) .. you may comment that that is the reason why you design the application so that changes can be done easily and with less expense .. how could the Y2K application be still used after 20-30 years and never upgraded .. the reason was it was too expensive to upgrade and also to migrate the data into the newest technology. My experience has been that any application that actually needs a change can be better implemented if you spend time actually re-writing the application i.e if you have the money and time .. not the whole thing in one short, but in bits and pieces .. I never said that I do not belive in mutiple layers or tiers .. I do strongly believe on that and do design that way .. what I was trying to understand is when and where do you draw the line between the layers .. but I feel trying to abstract a lot trying to support a requirement that is not known or assumed might also be not good. Looking at your comments, I assume you would support a design which does not pass objects like the datatable, dataset etc. from BL to the DL... Some may argue that this is part of the data layer and information passed from the data layer to the business layer and and back to UI must be through objects and properties ..
and yes, i did mean session objects for state management and cache for performance ..
anyway, thanks a lot for your time and thoughts .. I will keep this question open for a couple more days and wait for your response... else I will close it ..
Thanks again ..
Rejo
>>Maybe you will upgrade to ASP.Net 4.0 in 5 years, maybe you'll want to switch to C#, or D%, or some other new language. Maybe you will want to start using AJAX.
Yes, changes are inevitable. But should you be deisgning your application solely for changes that you are not even aware of? Any good design will be looking at business requirements and not trying to design a application which will support furture software changes .. atleast I have found that to like "trying to shoot a moving target" .. I have seen application which remain the same way without changes just because changes are too expensive (Y2K was a classic example) .. you may comment that that is the reason why you design the application so that changes can be done easily and with less expense .. how could the Y2K application be still used after 20-30 years and never upgraded .. the reason was it was too expensive to upgrade and also to migrate the data into the newest technology. My experience has been that any application that actually needs a change can be better implemented if you spend time actually re-writing the application i.e if you have the money and time .. not the whole thing in one short, but in bits and pieces .. I never said that I do not belive in mutiple layers or tiers .. I do strongly believe on that and do design that way .. what I was trying to understand is when and where do you draw the line between the layers .. but I feel trying to abstract a lot trying to support a requirement that is not known or assumed might also be not good. Looking at your comments, I assume you would support a design which does not pass objects like the datatable, dataset etc. from BL to the DL... Some may argue that this is part of the data layer and information passed from the data layer to the business layer and and back to UI must be through objects and properties ..
and yes, i did mean session objects for state management and cache for performance ..
anyway, thanks a lot for your time and thoughts .. I will keep this question open for a couple more days and wait for your response... else I will close it ..
Thanks again ..
Rejo
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
thanks for your time ..
Rejo
Rejo
ASKER
I am sure most of the exprerts out here have designed web application and have followed some architecture or have learnt some flaws in their design and they have ideas and views on how to improve on it the next time ..
If you could at least point me to some links that you might have found which you think is an interesting one to read on this topic. I have searched and have not been able to really get some good articles which has practical real-life examples.
Thanks again ..