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?
Related
I have a web application which is having an asmx web service holding some web methods. Those are being called through jQuery ajax method to get data or do various operations.
I want it to be accessed by only my web application and no other ways to call the web methods and this should be a fully secured one.
Can any body suggest on what are the security threats might affect my web methods and how i can protect them from those threats ?
Any suggestions are appreciated.
If you are using session state then you can use this
[WebMethod (EnableSession = true)]
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.
I'd like to be able to create standard POCO service that I can use in two distinct workflows:
in-process i.e. consumed by my ASP.NET webforms application
remotely via an exposed WCF endpoint to be consumed by other applications
Is there a way to re-use the same service and its return data types in both scenarios above? Ideally, my core service and data types would not have to be decorated with WCF specific attributes and I could add these attributes in some kind of WCF facade layer.
Thanks!
Since .NET 3.5 you don't need to decorate your data objects with WCF related attributes (DataContract, DataMember). If you don't use them default serialization will be used - all properties with public getter and setter will be serialized (also class has to have public parameterless constructor).
Sharing "service" layer works exatly as you have described. You create business service layer which exposes functionality. This functionality is consumed in-process by your ASP.NET application. Than you create wrapper layer which is marked with WCF related attributes and exposed as WCF service. Your WCF layer can be handled as facade and compound several business calls to single web service call.
Makes it sense to use ASP.NET togehter with WCF RIA Services or WCF Data Services ? Or are these technologies/frameworks only proper for Silverlight primarily ?
You can use RIA Services with ASP.NET, for example with DomainDataSource server control, or from an MVC controller.
The key thing is a DomainService in RIA Services encapsulates business logic in a presentation-tier neutral sense. It can be exposed as a service to Silverlight and Ajax apps, or it can be used by asp.net to do server-side rendering.
For example, a scenario is that of generating sitemaps and downlevel-rendering for SEO purposes, even if the presentation is silverlight-based. Both of these build on a domain service to share business logic.
Hope that helps.
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.