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.
Related
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.
we would like to use simplemembership provider in our app. However, we feel like validating that a user is in a role should be a part of the business logic. Simplemembership requires a dependency on System.web which we would not like to reference in the business logic.
Is there a way to decouple System.web from simplemembership provider?
I am not sure I agree that validating that a user is in a role should be part of the business logic. I would like to hear more details about this reasoning. But if you are going to put authorization in the business logic here is a method that still decouples the security model from your business model. This article explains how to do it using the new ASP.NET Identity used in MVC 5, but the same concepts will work with SimpleMembership. Dependent upon your reasoning for moving authorization into the business logic, the approach described here may also meet your requirements.
It appears from your comments that you are trying to reuse the authorization logic by placing it in the business logic, therefore not having to rewrite the authorization logic for each type of client that you put it in. But the fact is the logic will be different dependent upon the client. Just take the example of comparing authorization for an MVC View as opposed to a Web API. The MVC framework actually provides two different AuthorizeAttribute for each because you want to behave differently on authorization failure. If authorization fails on a View you want to redirect to the logon page. If authorization fails on a Web API call you want to return an HTTP unauthorized error. Two different behaviors for different types of clients that could access exactly the same business logic.
I think coupling your security logic with the business logic will actually make the business logic less reusable across different implementations. In Microsoft's Business Layer Guidelines they specifically state, "Do not mix authorization code and business processing code in the same components." I would further decouple your security model from the application by using the approach described here. This will allow you to change your security model at run-time instead of having to recompile and redeploy your application. And the security model will change.
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)
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 have a business logic layer (the "repository") which is exposed as a set of .NET interfaces backed by swappable concrete implementations.
Originally I had this business layer implement authentication and authorization (authn/authz), meaning I had interfaces such as IUserIdentity and IUserRole, and all methods that accessed sensitive data took an IUserIdentity and performed authorization before allowing the action.
The business layer has been very front-end agnostic up to this point... but now when I am trying to integrate into an ASP.NET web site, I realized that ASP.NET itself has a rich authentication/authorization system built into it via the Membership and Role APIs.
So the question is, should I remove all the authn/authz from the business logic layer and rely on the web front end to do this? This would simplify things alot but I don't know whether I will later regret moving it out.
The alternative is to keep the authn/authz in my business logic but integrate it with ASP.NET via custom Membership/Role providers. However this seems real cumbersome... I still need to investigate the cost of doing this.
What would you do (or have done) and why?
I think security is a cross-cutting concern that belongs in aspects. I don't know if .NET has aspects, unless you use Spring.NET.
Keep it. Forms Authentication in ASP.NET is very easy to customize and your business logic layer remains front-end agnostic.
Consider staying away from this approach and instead try Forms Authentication. Basically, you can call your established methods from an Authenticate event of a Login control.
I suggest you keep the existing logic, and write a custom membership/role provider around your existing security classes if you want to use the same directly using asp.net. This should be easier than you think.
http://www.codeproject.com/KB/aspnet/customaspnetproviders.aspx
As you already have classes for managing security permissions, this just means wrapping your existing logic.
This will also help you to use your security logic later, let us say, when you create a Winform client that consumes your business logic, or when you expose your business logic as web services
Are you planning to use multiple front-ends (asp.net, winforms, mobile?), or exposing the business layer via (web) services? Then you should probably implement authentication on top of the business layer.
When all you want is to grant / deney access, you could use integrated security on IIS, and never wite custom code for it.
You could also look into the asp.net membership provider.
I believe the Role Based security should be in the Business Layer, which is where CSLA puts it.