I was recently discussing with colleagues a push toward disciplined n-tier structure for our web application. It struck me that I couldn't think of any alternative.
Is it always the case that one should seperate out web applications into layers?
An alternative to the traditional N-tiered architecture is the Command-Query Responsibility Segregation (CQRS) architecture as discussed by Udi Dahan.
Like all architectural decisions you should really think about when to use it as discussed here
Personally, I tend to see a lot of "over architecture" in my software travels which can really over complicate matters and make things much more difficult to maintain and obviously cost a lot more too. You really need to think a lot about the business problem first rather than just picking an architecture.
Keep things as simple as possible for best results and easy refactoring.
Is it always the case that one should seperate out web applications into layers?
You should separate different logical parts of your system to avoid them being tightly coupled which turns makes them and more reusable. Into what you separate them is not really that important. You can call it layers or whatever.
Actually there could be 2 meanings of those layers:
Physical boundaries: client browser, web server, web services server, backend database, ...
Logical boundaries: GUI, service layer, DAL, ...
You might also take a look at the Onion Architecture. But onions still have layers :-)
It is highly recommended to read Microsoft Application Architecture Guide, 2nd Edition.
Then, you'll realize how important that separation is for every site which is anything more than 2 simple web pages or so.
It is a thorough guide that explains every layer's roles and responsibilities and how they all play together in a robust & scalable application.
You don't have to read it all, but for the beginning take a look at Chapter 5: Layered Application Guidelines.
There is an alternative "pattern" to Layered Architecture.
But it is the anti pattern that the Layered Architecture is trying to solve. Namely the "Big Ball Of Mud" :)
Related
I'm slowly getting into MVC, but it's still relatively new to me. From what I've discovered by doing a few tutorials, MVC provides an interface for communication between the database and the website and in general allows for better organization of the code.
Are there other significant advantages to using an MVC structure? What would be an example of a time when you wouldn't want to user MVC, even if you are communicating with a database?
Thank you!
Technically speaking, MVC has nothing to do with whether or not an application uses a database. MVC is about separating concerns so that the things that represent business concerns and logic [the models] are separated from how the UI is displayed [the views]. It doesn't matter whether or not your models are stored in a database, on the filesystem, in memory, or not even persisted at all.
As for when would you NOT want to use MVC, that's harder to say. MVC is about separating concerns to simplify the construction and management of a software system. If you don't need those benefits, or if you get greater benefits through a different pattern (for instance, if you have a team that's highly skilled in a non-MVC based framework), then don't use it. It's certainly possible to build good software without using the MVC pattern, the pattern just helps.
The pro/con list in this blog may help you understand when MVC makes the most sense to use.
http://www.ytechie.com/2008/10/aspnet-mvc-pros-and-cons.html
You can take a look at this video: Choosing the right programming model.
Since you indicated you're a beginner with MVC I suggest you take a look at these informative tutorials.
Let's say you have an intranet development team where it is in your best interest for each developer to be happy with their work - one person leaving will negatively impact the others. Some developers wish to embrace the Web (i.e. ASP.NET MVC). Others wish to work in a stateful environment where Web is merely the medium for delivery (i.e. SilverLight).
I don't want to argue the merits of either (I have my opinion). Rather I want suggestions for legitimate arrangements such that we can have our cake and eat it too. Is it possible for some members of the team to work with SilverLight while others work with ASP.NET MVC without ending up in pandemonium?
I'm thinking that MAYBE we could have ASP.NET MVC for the majority of our applications and then have the SilverLight people develop components that can be used in the UI? But according to this question that didn't turn out so well.
I'm just looking for a scenario that would allow the team to effectively use SilverLight and/or ASP.NET MVC in their work (not necessarily in the same app) without imploding.
Any links to articles with information pertaining to how well a given scenario works would also be appreciated.
Unfortunately you can't make all of the people happy all of the time.
...which is what it sounds to me like you're trying to do. You have to pick the best technology that suits your application and roll with it. Trying to mix and match technologies just to keep people that want to use one or the other is going to fail.
If your application has legitimate uses for both ASP.NET MVC and Silverlight, then by all means give the Silverlight development to the people that want to do it and let the ASP.NET MVC people handle the rest. Just don't introduce Silverlight to give the developers who want it something to make them happy.
We have a mixture of Silverlight and regular ASP.Net on my team. It's a pretty big application but about 50% of it is Silverlight apps. People who want to work on Silverlight do that and the rest of us do web development. There is one big .sln that has all the projects and a bunch of smaller ones that have projects related to specific functional areas in the app. We have a build process that compiles everything and puts it all together.
Which parts of the application are SL and which parts of the app are HTML depends on a combination of business requirements and end user capabilities -- NOT whether the dev just want's to do SL or HTML.
If you want both do co-exist in your environment, you will need a process and it should revolve around business requirements and not just what fun toy a dev wants to use.
I think you should re-examine your assumptions. In particular:
One need not develop with MVC to embrace the Web; Web forms + Ajax works great in many scenarios.
Silverlight apps don't need to be stateful. In fact, Silverlight apps don't even require a UI.
IMO, the best approach is to start with a detailed architectural design for your site, and to look carefully at where each technology might be best applied. With an architecture in-hand, you can begin design and agile development, and let developers choose which areas they would prefer to be involved with, subject to overall project management constraints. But the key is to have the architecture drive the technology choices, not the other way around.
We are building an ASP.NET application (with C#.net as language) and will be hosting on Windows Server 2003 Operating System with SQL Server 2008 as database.
We are planning to implement the best practices in writing code, dividing the application into logical blocks, services etc.
Would you please guide me on this, if you have an idea?
If would be great if you could also provide a reference document or web references (If needed).
Many Thanks,
Regards,
Venkat.
This isn't what you want to hear, but your best bet might be to bring on a senior asp.net guy who has a lot of experience and put him in charge of this.
But that's an extremely broad question, Venkat. Maybe if you could narrow it down a bit more we could provide a more useful answer.
I would perhaps recommend one book called Framework Design Guidelines, which is published by Microsoft Press. It goes into a lot of best practices on writing code, naming conventions, how to design classes, etc. And there are dialogues in there between Microsoft's top language guys. Sometimes they disagree, and that's always interesting.
But that's just one piece of the puzzle. I could talk for hours about methodologies, architectural patterns, object oriented theory, seperation of concerns, etc. As stated, your question covers all that ground.
You have a good software product, so why would you make it SOA compatible?
You may want to do this to provide a looser coupling between your data services and your application layer. This will give more flexibility to reuse the service components for other products and allow you to change the underlying service architecture if need be without the need for your application to even know about the change.
Having said all that, I would first want to have an actual business use case that warrants making the switch before making the change. Changing simply to keep up with the latest buzzwords is just a waste of money. If you're starting a new project, however, you may want to consider a service-based architecture if it makes sense for your application.
In my opinion, only one good reason: you need interoperability between different platforms or technologies. Otherwise, save yourself a lot of grief and "just" make a well-mudlarized architecture - tell your boss it is SOA if that's what he wants to hear. Don't do it because you might move to or use other platforms in the future - you don't have an interoperability problem yet.
If you want your product to be integratable with other applications and your customers have actually voiced this wish / requirement then I would consider it, but otherwise it might be a big waste of time and money, especially if doing it might cause some lengthly architectural refactoring to make it work. But with no clear reason, it probably doesn't make sense to follow a trend just because others maybe doing it. Your customers will let you know when this is necessary.
That's a very difficult question to answer without more detail about your "good software product", but speaking in sweeping generalities:
If you implement an SOA scheme on your product, more developers will be able to consume the API services provided by your product because web services work across almost any development platform.
If your product is already a web application that publishes certain data, you might discover that you have readers/consumers of your data that are interested in doing analysis or building additional applications that you never thought of or may not ever have the available time to build.
The fact is: you don't need to.
SOA structure is very complicated to achieve. It requires care and organization style that I believe most companies will not have. (I'm glad if yours has such organization).
Tomas Erls talks about Contemporary SOA and Web Service First Generation. WS-I is the traditional web service style such as asp.net web services. Actually this traditional web services doesn't mean any service oriented; And what happens is people build simple web services and call them SOA.
Contemporary SOA, I believe, is an entire system structured based on services. Inside this "ecosystem", services would call each other to perform some tasks.
SOA analysis is painful and you need care. To build an ecosystem like that, you need to be prepared from the first moment.
Engineering service interfaces (contracts) is also paradigm. If you put some Lean Thinking at your belt, you should cut some desire to make state-of-art design.
If your system already works, fine! If someone will need integration in possible future which you don't know yet about it, don't do it now. But if your system is born to be consumed, them you think about it.
Best
I have a web application that is arranged into data, business and UI projects. As the system evolves changes are deployed by building all three projects and deploying them in one package. This has worked well and has allowed the illusion of “three tiers” without tackling the communications, versioning issues of truly separate systems.
So along comes a request for XML summaries of some of the data and my thoughts turn to a fancy WCF service that, one day, could be my “Web API” (ahh… the mind.. what a evil little monkey it is). So, assuming this survives the “is that really the best idea?” test here is my question:
What structure have you had the most success with when posed with two
evolving “clients” serving content from a single evolving “model”?
James, your question is rather board as there are a large number of variables that go into choosing the right type of architecture for your needs. I would recommend reading the patterns & practices Application Architecture Guide 2.0 to better understand the options and pick the best one that suits your individual needs.