We are planning to use EXTJS framework for presentation layer which would be calling WCF based Rest Service or WebAPI Service(Http services) . My requirement is to have 3 tier architecture (physical separation) so my understanding is that we need to put Service layer on another server and host services on IIS there to be consumed by presentation layer hosted on different IIS server.
I am getting few doubts regarding this architecture.
Should we use Webform approach to host EXTS libraries as in this case ASP.Net MVC would be irrelevant considering that all the rendering logic is done by EXTJS.
If we host services on another server which service authentication should be used .In this case I think we can’t use Form Authentication as the web and service are hosted separately.
Is it really required to host Service layer on another server to make it three tier ,considering the third tier is the Database server. Isn’t browser a tier considering EXTJS library directly renders on the browser.
Since no body answered i will try to answer myself based on my research and response i got from another forum.
We can use MVC approach as well, the Controller method can be used to return JSON result for the EXTJS API to consume. But the downside is with this approach we cannot use strongly typed model in views along with other features like use of Html helper and automatic validation based on the models.
With this approach we can still use MVC routing or can go entirely with a Single View and ExtJs Routing.
Place the services your Ext.js needs on the web tier, where your Webforms/MVC application also runs. Separate your business logic/data logic via other services on another server if needed (second tier). Don't call these directly from your Ext.js. Keep presentation in the first/Web tier.We can use Form Authentication to call service in web-tier and Windows authentication to call the service from Webtier to second tier.
From the server side perspective a browser's not really considered a tier.However with modern approaches it's debatable.
Related
I have a large enterprise application with specific domain logic and validation with external domain services. Validation layer already implemented in the base system.
My api uses data transfer objects for client-server messaging, but validation in ASP.NET Web Api suggests use Data Annotations attributes or IValidatableObject interface in model classes (or DTO).
How I can integrate my legacy validation system with ASP.NET Web Api validation?
Thanks.
It sounds like your validation layer, being logic that you have around your domain level objects, doesn't necessarily need to be "integrated" with your web api in the interest of keeping these separate.
For the api validation, you're either going to add another level of validation in your api using the Data Annotations/ModelState solution (or manual validation checks in your controllers) or handle the exceptions that bubble up from your domain validation in your service layer, where you can format and respond appropriately to the consumer.
As a learning exercise i want to create a simple web api and consume it using a web client(asp.net mvc) and a desktop client(winform).
The web api must handle categories, products and of course users/roles as follows:
everybody can browse categories and products
regular users can insert/update/remove products
administrators can insert/update/remove categories and products
Regarding first consumer, the asp.net mvc application, i have the following questions:
In controllers, will be anything else than ViewResults, because from what i understood all http requests are made from javascript?
What about authentication and authorization?Since we are talking about a RESTFUL service, there is no connection between calls and the user must send in every request some piece of data to identify himself.
2.1 Is there any point in using HTTPVerbs ( in ASP.NET MVC apllication) ?
2.2 What about FormsAuthentication?
2.3 How do i safely send the credentials to the web.api?
Everything is so blurry for me, is there any example with some web api, hosted in the iis independently and consumed by an website (ASP.NET WebForms or ASP.NET MVC) because all examples i have seen weren't that clear.
1) In controllers, will be anything else than ViewResults, because from
what i understood all HTTP requests are made from JavaScript?
Not necessarily. You could perfectly fine use the HttpClient (the Web API Client classes) to consume your RESTful actions directly from your standard ASP.NET MVC actions. For example you could perfectly fine have a repository which uses the HttpClient to consume an ASP.NET MVC Web API method to fetch the data instead of querying a relational database. You should not necessarily expose your WEB API methods to client side JavaScript. They could serve as a gateway to your data access. There are many possible scenarios of course.
2) What about authentication?Since we are talking about a RESTFUL
service, there is no connection between calls and the user must send
in every request some piece of data to identify himself.
There are many ways to perform authentication. One of them is to use Forms Authentication which is a well established mechanism involving cookies. So the piece of data that will be sent from the client to identify himself is actually a cookie in this case.
2.1) Is there any point in using HTTPVerbs?
Of course. REST is all about HTTP verbs. In the case of ASP.NET Web API it is the HTTP verb that determines which API controller action to invoke by convention. You could of course violate this convention by overriding the default routes setup.
2.2) What about FormsAuthentication?
See point 2)
I have Data Tier, Business Tier which contains interfaces for the data tier, and presentation tier of asp.net web application.
I want to add web services (not wcf services!) that will use an interface.
Where should I put the interfaces for the web services?
Where should I put the web services implementation?
How can I combine the web services implementation with the asp.net web application?
Have you tried Web Service Software Factory (and on MSDN)? You can find guidance and best practices (even for asmx web services)
I like to think of asmx as a technology to expose functionality in your application. I write business services (BS) instead, unit testable, usable by a controller or aspx code-behind in your case or an asmx web service's implementation.
The asmx web service then exposes only the methods of the BS I want, it instantiate a BS and forward the result back to the caller (using its own "data contract" objects).
I would abstract them out and treat them just like data access (so at the same "level" as data access but in their own "slice").
See below for an answer on where to put an email component - which to me is exactly the same (in principle) as what your asking:
Does sending an email belong in the presentation layer or business layer of an application?
Should I access the asp.net membership class from the controller and pass the results to the service layer, or access it directly from the service layer?
I'm torn because on one hand this seems like business logic that should be handled in the service layer, but I don't want to tie the service layer to the web namespace as this might become an windows app down the road.
the answer, use IoC to create a membership interface that the service layer uses. the website's implementation can use the web namespace. And the windows app can have a different implementation. and since you can inject that dependency, your service layer doesn't have to change :-)
ASP.NET Membership is Web-specific, so that should be accessed in the Controller. MHO is that the service layer should not be hard-wired to the web. So for adding/removing users, do that via the Controller.
OTOH, in the service layer, you can read Thread.CurrentPrincipal.Identity, which is non-web-specific, but happens to be entirely compatible with ASP.NET Membership. So if you only need to get the current user you can do that without voilating separation of concerns.
Is it really a problem to use System.Web? It's no different than tying it to System.Configuration, or System.IO. Any application can make use of it, whether it's "offline" or not.
I routinely tie my web apps to assemblies that are more classically though of as "winforms" assemblies, to get access to useful collection objects and such.
I am getting my head around n-tier applications. I understand seperation of code layers eg/UI, BL (Business Logic), DL(Data Layer).
In a ASP.Net application you would just reference the C# project that is doing the BL and the DL and all is well.
What I don't understand is how you would implement this on seperate servers? Do you have the DLL for the BL and DL in the bin folder but a setting in the web.config file which tells it where to go for communication or do you have the actual BL and DL running on a seperate server and then communication from the UI is made via a web service?
At the moment I have a standard ASP.Net webforms app that needs to seperate the security side to the web server and the main app on a application server, however I dont think thats possible.
When we spit in to physical Tiers we use WCF between the tiers. You actualy end up getting many more layers in your application, so do not use it if you do not need it.
Typical layers would by
Client Tier
UI
Business
proxy
Server Tier
Facade
Business
Data access
Server Tier can be implemented as a single Layer if you use an ORM.
This isn't directly possible without clustering, and even that requires exact copies of the application running on both servers.
If you want to run your security layer as a separate server, create it using web services, and make a web request to that service, and return the (encrypted or otherwise) response.
Hope that helps.
EDIT for continued Explanation:
In your case, I would have my security application running on a server that will authenticate, encrypt, and respond to requests made to it from a specific url or domain/sub-domain. Then my main application can live on another server and the requests to authenticate etc can be on a secondary server. However, ASP.NET authentication uses the machine-level key to create a unique salt for the authentication token. So in order to share auth tokens between multiple machines, your machine keys must be identical in the machine.config.
Separate servers would entail the usage of some form of web services. Here at work:
Server (piglet) - database, sql server 2005, firewall prevents connections to tigger
Server (eeyore) - web services - connects to piglet
Server (tigger) - asp.net server - connects to eeyore, firewall prevents connections to piglet
The business logic would be in a dll assembly used by the data access layer, the presentation layer, or both, and is deployed alongside them.
If you want the layers on physically separate servers, then you have to decide how the layers should communicate. You have lots of options for doing this: web services, Windows Communication Foundation, .Net Remoting...
Application Server - Instead of calling the security logic directly, call a security webservice on the web server.
Web Server - Hosts the security webservice. The webservice here does the actual business logic and can call the data layer.