For clarity when I mention tiers in my question, I am referring to physical tiers (i.e. different servers for presentation, application and database)
My company has a public facing website that is currently built as a typical 2 tier system (web server and database server).
Soon a project will start in which we will be re-writing the whole site. We are required to split the project across 3 physical tiers. Actually, when you consider the browser then you could consider it 4 physical tiers.
In my experience most asp.net applications are built on 2 tiers. The web application itself may have several layers but physically it is deployed to two servers (web and DB).
I have searched for examples but it seems that layers and tiers get confused. I see a lot of multi-layer examples but no multi-tier examples.
In a nutshell it would seem that the web application makes web service or WCF calls to the application layer that marshals data to and from the database using ADO (or L2S or EF).
Does ASP.MVC help achieve this? Does it make it any easier or just different?
Is there a good reference or example of this somewhere?
I don't think adding another tier increases security, but it definitely slows down performance and significantly increases development cost and complexity.
In the end, you can partition your application with an additional tier anyway you want. If it were me, I'd probably create the dumbest pass through tier I could if I was given this "interesting" requirement.
In fact, managing security around another tier implies significantly increased opportunities for security holes to be accidently exposed.
ASP.NET MVC should have no impact, but you will likely end up using something like WCF. For marshalling data back and forth, you probably want to use DTOs which are not tied to any particular database or ORM.
This is not a situation I'd be happy to find myself in. Increased complexity does not lead to increased security.
Gday Rick,
I work for a company that has the same multi tiered policy due to security.
I have an ASP.NET MVC web application on one tier that connects to a application tier that a web service sits on and is basically a facade for the database and a mainframe. Pretty much exactly the same as your setup.
ASP.NET MVC makes it really nice and easy to use this setup because you can easily build a validated object model in your ASP.NET MVC application. Once the object passes all top end validation you can easily transfer it on to the application tier via a web service.
I suppose this would be easy to do with a classic ASP.NET application however I think MVC makes things a lot easier!
Check out my blog for an example of how I have validated my models before sending to the application server.
Cheers,
Michael
In my opinion ASP.NET MVC isn't going to help, or hinder this scenario. Basically you'd going to have your model exposed not as Linq2Sql, the Entity Framework or any other ORM but from the middle tier, probably by WCF.
This presents the usual challenge around authentication and authorization - namely how does authentication flow between tiers., but that's are unique to MVC, a WebForms solution would have the same sticking points You'll also lose the model validation bits that an ORM may supply and will have to provide that yourself in your web services repository, but that's just a matter of implementing the right interfaces.
This is an odd requirement. Did it come from the customer? It is possible that some customer education is needed.
I know J2EE systems can be split over three tiers, with web server on the first application server in the middle and a DB on the back end but I havn't heard of this with .NET.
As mentioned before... MVC won't really matter in this situation. The closes analogue I have is we had a financial client separate out their web services into tiers...
so something like
1) public facing load balanced web services
2) web services
3) application code
4) database code
I don't remember if layer 3 and 2 were physically separated (been a while) but essentially layer one was fairly thin and just threw the requests over the dmz to the inside service.
So you could probably do something similar with the web site... potential for bottlenecks, but would get you the physical separation you need.
Good Luck!
Related
I need advise on the architecture of my new application. In the environment I work in, we normally create Win based apps and these compose a UI layer, Business Layer, WCF Service Layer, and Data Access Layer. These are on a 3 tier architecture with Services Server, Database Server and clients machines accessing the application via Citrix on an Application Server. I just created a web aplpication and my admin has suggested this should be hosted on a separate web server, my question is, is there a need for my web application to use a WCF Service Layer, since it can be hosted on the same application server? Basically, do websites need to use wcf/service layers and what are the benefits?
1.
Read this:
http://www.codeproject.com/Articles/10746/Dude-where-s-my-business-logic
My advice:
At the least, you should use WCF, and use "named pipes". You can deploy both the Host (WCF) and the Client (Asp.Net website) on the same machine.
The Asp.Net website will be the "client" and access the service.
Then, if you ever want to horizontally scale, all you have to do is change the .config settings to use a different protocol besides named-pipes.
Aka, you'll have the "logical separation", even if you deploy both on the same physical machine(s).
They (websites, any project) don't "need" to do anything.
You can write inline sql code behind buttons on webforms if you want.
But its not maintainable. And its not scalable. And it is probably foolish.
But putting in the time to SOA a mid to large sized application is worth the effort in the beginning, IMHO.
This is a question without a concrete possible answer, do you need a wcf? well that depends on the requirements and the architecture you want to put in place.
based on the small context you provide maybe you can get some the following benefits
WCF Provide state for operations
Fast processing (binary serialization)
WCF are more likely 'to be testable' than legacy asmx web services
You can access the same backend you built for your desktop applications
regarding if than can be accessed from the same server, the short answer is yes (obviously you need to measure your server capabilities)
I've done some app's that doesn't use a wcf at all, and other that use it for certain operations you can take a look to this SO answer to get a good example where a wcf could be a good candidate in an app.
Can I convert a non-MVC asp.net application to be Azure compatible ? Or If i want to create an Azure web application, should it be MVC one ?
The other answers answered your question about converting your app to MVC for deployment to Azure (you don't need to).
If you're creating a new web application and go with ASP.NET MVC (which I'd recommend), just remember if you go with MVC3, you may have to make some of the MVC3 DLL's CopyLocal for your deployment, as it won't be part of your web role instance. At least that's how I still understand it. The 1.4 SDK of the Azure SDK doesn't have a MVC3 Web Role template yet.
See this post on steps to get your MVC3 app Azure-ready.
Hope this helps.
You may take a look at the following blog post for migrating an existing ASP.NET application to Azure. It should not necessarily be an ASP.NET MVC application. Any ASP.NET application will work.
azure has 2 roles
1. a webrole
2. worker role
web role is nothing but an asp.net app. so no need to convert it into an MVC app just any asp.net thing will do fine
Yes, you can. But you need to be aware of certain limitations too, none of which were mentioned in the answers already given:
Your application should be stateless, unless you are running a single instance (for most apps 99,9% reliability is OK, but there are some where you want 99,95%, so you need at least two instances + it gives you additional benefits of a load balancer, etc.). The reason for this is that if you have more than one instance, the load balancer will deliver the request to a different instance. You can use AppFabric Cache to solve this.
You don't have a file system - this is not entirely true, but in reality you should never rely on having local files. All you image uploads (e.g. user profile pictures) should be uploaded to a blob storage and linked to there. How you do this is another matter, and one that can be approached differently depending on the architecture of your existing application. You can get away with files, by using Azure Drive, but it's slow as hell.
No Event Log / RDP - this is also only partially true, but you should rely on other ways of getting diagnostics information from your role. While you can RDP to your role instance, there are better ways (e.g. Azure Diagnostics storage).
Database should be chosen carefully. Sure, you have SQL Azure available, but it's expensive (1 GB = 10 USD/ month). If you can get away with stuff like Table Storage, you may save on some costs. Again, this depends a lot on the architecture.
As for the second part of your answer. MVC as a pattern is nice. It saves you a lot of time, it's much more adapt for the Web as WebForms ever will be. The event based system was designed for Desktop applications, and it was forced onto the web. However, going to Azure does not imply a requirement to go to MVC. What I suggest you do however, is treat it as a nice jump-start opportunity to look into MVC and see how it could help you write your apps better & faster.
As with any other case involving architecture of apps, it depends. If you used common patterns (e.g. IOC, Repository), you will have a really easy time moving any app to Azure.
I am starting a new project which will need a ASP.NET MVC 2.0 website, a Silverlight section and a Windows Phone 7 UI.
My plan was to use WCF RIA Services to create a set of services which would be used in all different UI projects. With the Silverlight project I would use the standard tool integration, the Windows Phone looks like it may have to be WCF Services exposed by the RIA Domain Services, but I'm not sure about the ASP.NET MVC website.
My initial thoughts I would simple reference the class library containing the Domain Services and use them directly. Could this be considered a viable approach to using RIA Domain Services in a ASP.NET MVC website?
Kind Regards
Michael
I know a long time has passed since this question was asked, but since I had to make such a decision, I might as well document it for the benefit of others.
I work in an environment where lots of legacy and new apps co-exist, with the legacy apps being phased out. So we've had to build interoperability between everything from MS Access, to web service end points in C#, VB, Web Forms, MVC 3, even Flex, Reporting Services...the list goes on.
One of the biggest pain points in a multiple-client scenario is the maintenance of interoperability over time. As data, requirements and delivery mechanisms change, keeping things smooth ends up taking a lot of resources.
My approach has been to create one and only one mechanism for reading a given source of data by defining 1) a model, 2) a serialization/deserialization layer and 3) a service layer. All projects that need to use XY_Data must use the XY_Service to get XY_Objects via the XY_Serializer. Direct db calls or stored procs, etc are allowed in the XY_Application. This allows me to drop in replacement DLLs (versioned) with bug fixes and upgrades without restarting anything. I hardly ever do a full publish.
So yes, what you're suggesting will work. I would recommend only that you rigorously enforce the single-source-of-truth and DRY policies both in your data and your APIs.
Is there a business case for using WCF WITHIN your web application (ASP.NET/SQL Server)?
I'm not talking about a service to be consumed by others, but rather a service to be consumed WITHIN the web app. So far, the only use for web services WITHIN the web app I came up with is when I need to call the database from the client (through AJAX).
Please don't give me the copy/paste lesson on web services, all I'm looking for is a CONCRETE EXAMPLE of WCF benefiting the web application, and NOT the other apps consuming the services.
Quick clarification: by "web application" I mean a self-contained CRM of sorts. It does a lot, but it DOES NOT talk to any external apps/db's, and DOES NOT need to have service points open for other apps to consume.
We have a Windows service that gathers live data from the web. Because the data is ephemeral (it's only really valid for around 3 minutes), there's no point in recording it in a database. To retrieve data, the Windows service offers a (TCP transport) WCF interface which is only exposed to the web-server, from which our web-app requests data.
I think it very much depends on how you define "application".
If you're talking about a single web application then with the exception of provision ajax data as you've already noted I'm struggling to think of a generic reason why you'd want to as a web service (even more so for WCF) is just an exposed API and if you're in the application surely it would be better (in all kinds of senses) to go straight to the API without the additional overhead of wrapping and unwrapping the calls and the data - which is pretty much redundant.
On the other hand if by "application" you mean an assembly of "stuff" that delivers a solution to a set (or even various sets) of end users then yes, of course... there is definitely a case where the flexbility of having components communicate via services outweights the overhead issue. Where it gets grey is if there is an assumption that a single application will (or at least might) later become multiple applications wired together - but if you're not doing it now then you're just causing yourself pain you don't need so shouldn't bother. If you need to split it deal with that as a self contained exercise as and when you need to split it.
One concrete example from my practice: On one web site we use actively tables which are implemented with respect of jqGrid plugin to jQuery. The contain of grids will be loaded per ajax. So the most pages of the web site are very simple and have clear XHTML code. The business logic with the interface to the database is inside of WCF service. Inside of WCF service we get data also from other information stores of the organization. In the same way if one will need later to have an input from our project the WCF service will be perfect.
So the usage of WCF WITHIN in our web application helps to archive clear interface, clear separation business logic from the HTML markup and better testability (with utit tests integrated in Visual Studio).
Looking into developing new startup with potential of hopefully having high volume.
Initial idea was to straight away have MVC talk to WCF services to create our Application Servers.
However after a little contemplating just wondering what benefits would I gain from using WCF services with MVC application?
If performance became an issue we could just keep adding new front web servers instead of application servers.
Enlighten me please, thanks
Don't start using fancy technology for the sake of using it or because it looks cool on paper. You'll have to support it and sometimes find yourself making things overly complicated because of the introduction of something that might not be necessary.
Said that, my current project also uses MVC 2 in combination with WCF. There it was an architectural decision made before I came to the project as they want to spread the tiers on different servers in different domains (outside and inside DMZ). The WCF service can only be called from the server hosting the MVC application so it should increase security.