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.
Related
Hi created my service using http://ntieref.codeplex.com/ n-tier entity framework.
The service the generator created uses wcf and wsHttpBinding. It uses windows authentication and the program created works fine when the user is logged in the Domain (as it should).
My problem is when I am trying to connect from "outside". I could not find a way to pass
something like this:
client.ClientCredentials.UserName.UserName = "SomeUserName";
client.ClientCredentials.UserName.Password = "WrongPassword";
thats why my call fails with the user not validated.
My question is specific to n-tier entity framework (http://ntieref.codeplex.com/) with the default generated. That's why I am not posting configs. If some one has experience on this framework please help.
I would like to also expose some functions of my own written on the server to the clients (beyond the entity generated functionality) (e.g. a login function that will return some custom class after validation) without breaking the existing functionality.
Where should I write my code ?
WCF Endpoint Configuration
The n-tier entity framework generates plain vanilla WCF services which can be exposed through any WCF endpoints. All you need to do is setting-up corresponding endpoint configurations in your config.
Custom Service Methods
Both, service contracts and implementation are generated as partial interfaces and classes. This allows to add additional custom services methods as required.
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.
I have a WCF service that is hosted in a windows service. It shares the same libraries as an ASP.NET project. The WCF service is used to process long running operations that I don't want the ASP.NET site running. I'm using Autofac to handle dependencies in both the ASP.NET and WCF project. Since I'm using ASP.NET, I'm using the InstancePerLifeTimeScope() method on all registrations. Since these same registration modules are also used in the WCF service, I was hoping they would create instances per WCF method call, but that is not happening. Is there a way to get Autofac to consider an object's lifetime scope the same as the life time as a service call?
I hope that makes sense.
Assuming you are using the Autofac service hosting mechanism, if you register your service-related objects as InstancePerDependency and set your InstanceContextMode to PerCall, each call should get its own dependencies resolved. Autofac doesn't have an explicit "per call" lifetime setting for WCF.
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.