As I read about software architecture (MVC, SOA, etc.), I had some questions: Why are so many architectures needed? What are the advantages of these architectures? How can I select an appropriate architecture for my projects? What are the guidelines I need to follow?
I read the blog of scottGu and he specified that MVC will help in search engine optimization. How will this architecture help in SEO?
I am not an "Architect".
But, MVC (in web development) makes each page look like you are calling a method on the web (in a simplistic sense of things). So, if you look at this question's url, it is more readable than having a url with question.aspx?id=1279140.
Search engines will be able to get the results easily from the URL itself, rather than having to pick things from the text of this page, if my understanding is correct :)
EDIT: On a side note, imagine if most sites had their URL like this one - you will be able to type in amazon.com/code-complete or amazon.com/mcconell. I hope you get what I am trying to say (a smart website, which can somewhat understand what you are looking for).
EDIT2: Thanks to @bjelli for suggestion. I said this with asp.net MVC in mind (specifically the way URLs are REST style).
You're referring specifically to ASP.NET MVC, not the MVC pattern in general. ASP.NET MVC heavily emphasizes constructing clean and descriptive URLs, and makes it easy and natural to develop applications that do contain clean and natural URLs.
Clean and descriptive URLS are a big advantage in search engine optimization since typical search engines rates text matching the URLs high.
Take a look e.g. at the URL for this question here on stackoverflow, it would not get that high a google rank if the URL for it was http://stackoverflow.com/q=1279226&page=1
MVC has very little to do with SEO. It's not a real architecture either. It simply makes sense to separate certain kinds of code. For example, if you make a separate template for articles, you can reuse it to display several kinds of articles. If you make a separate Model for a certain type of article, you can use that type on different pages easily.
Some random ramblings:
(Note: I talk about architecture the concept, not architecture the artifact)
The architecture of a system is the overall design and make-up of a system. Architecture is always present, but you might want to make sure your architecture is good enough. Basically architecture is be done as part of the development process; up-front, during the development or accidentally. Avoid the last one.
One reason for doing some up-front architecture is to find out which decisions about a system you need to make early (due to interoperability, for example) and which you can postpone until you actually need it.
If you mind your architecture continuously during development, making sure you always have a clean structure (and not being afraid to change it when the right reasons are given), your system will be much more easy to extend and modify as needed.
I find that a mix of the two is good, trying to find out the necessary Big Decisions early and try to delay making them as late as possible (but no later!) when you have as much information as possible to base your decisions on. Early architecture is also useful for determining the smallest parts needed to get a minimal working system which can grow as the requirements become clear.
Also, architecture can be seen as a communication tool; by using well known architectural patterns and metaphors it becomes very easy to communicate the intent and workings of your system to other people. A well-architectured system can be recognized by being easy to understand in layers of pieces; you can understand one part without having to know the details about all other parts. It is basically the tour-guide and road-signs to the system :)
The Blog article you're referencing argues the advantages of MVC very well:
One of the benefits of using a MVC methodology is that it helps enforce a clean separation of concerns between the models, views and controllers within an application. Maintaining a clean separation of concerns makes the testing of applications much easier, since the contract between different application components are more clearly defined and articulated.
The MVC pattern can also help enable red/green test driven development (TDD) - where you implement automated unit tests, which define and verify the requirements of new code, first before you actually write the code itself.
There two ways in which I understand your question. I'll answer both.
Why are there different architecture pieces? Well any application has different areas with their own challenges: UI, Interfaces to other systems, persistence. They are to a large extend independent and different, so each has their set of architectual patterns, that you can apply.
Why isn't there one perfect architecture that we all use? Architecture is the art of making trade offs.
-Do you want a fast application?
-One that supports billions of records and hundred thousand users?
-One that is easy to install?
-One that is easy and fast to develop?
-One that is as secure as Fort Knox?
-As easy to use as Google
-should it be available 99.999999% of the time?
For different targets you need different architectures. On that solves one won't be usable in another case.
There is no proof that so many architectures are needed. It's just that too many people believe they can come up with a new perfect architecture that will solve all the world problems. You have people in standard committees, R&D departments of companies, university departments that try to gain momentum in the scientific community be continuously inventing... well just about anything really.
I will probably get downvoted for overciting Joel, but he keeps writing great stuff. Read this article, it will provide much insight into what's going on.
Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That's probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can't spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don't have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it's just cover fire so that they can move forward and you can't, because this is how the game is played, Bubby. Are you going to support Hailstorm? SOAP? RDF? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond? The sales teams of the big companies understand cover fire. They go into their customers and say, "OK, you don't have to buy from us. Buy from the best vendor. But make sure that you get a product that supports (XML / SOAP / CDE / J2EE) because otherwise you'll be Locked In The Trunk." Then when the little companies try to sell into that account, all they hear is obedient CTOs parrotting "Do you have J2EE?" And they have to waste all their time building in J2EE even if it doesn't really make any sales, and gives them no opportunity to distinguish themselves. It's a checkbox feature -- you do it because you need the checkbox saying you have it, but nobody will use it or needs it. And it's cover fire.