I have a bunch of WCF services referenced in my Desktop Application.
All of these services have some common methods e.g. GetAll(), GetAllAsync(), Add(record As Employee), AddAsync(record As Employee).
Now, while creating a Inheritable form, is there a way I can make generic functions for these common service functionalities so that in inherited form I can only provide the service name as type.
Related
Good day all.
I have an asp.net core solution (NopCommerce 4.4) where I'm registering multiple classes that inherit from Microsoft.Extensions.Hosting.BackgroundService. These are using Dependency Injection to get access to several other classes at runtime.
Some of these DI classes need to know which specific class (derived from BackgroundService) they were instantiated in so they can return data specific to the background service that's "hosting" them. For example, each Background Service has it's own ECommerce Store it's responsible for processing data in.
How can I determine what Hosted Service is the "context" for the DI classes that it is requiring?
Our WCF service solution consists of three projects:
Business Logic (AddressChangeBL & AddressBL)
Entities (POCOs) (Address)
Service (AddressChangeService & AddressService)
Now, the service project has two separate services, each exposing the same entity. When I reference the service in an ASP.Net application, the same entity is referenced via two different namespaces (AddressChangeService.Address & AddressService.Address)
In my code, I need to send an Address entity to both services. First to the AddressService.IsValid method, then to the AddressChangeService.UpdateAddress method.
Even though, in the service, the Address entities are the same class, in the ASP.Net application they are two different classes.
How do I go about resolving this issue?
I know of a couple of workarounds, but none are good for us:
Add a reference to the entities directly using the Entities assembly, not via the service. This is not an acceptable solution for us, as our requirements demand that we use the entities created by the WSDL.
Move the IsValid() method from the AddressService to the AddressChangeService. This is not acceptable either as it violates our desired separation of concerns.
I would like a "solution" rather than a "workaround, if possible.
The problem is that the classes ARE different. They may have the same signature, but they are different (C# isn't duck typed).
The reason is that when you "referenced" the service you used "Add Service Reference". What this does is it generates a new set of classes to work with the service. Since you added two services, two sets of classes were generated.
The solution is to use the option "Use Existing Types" (or something to that effect) when adding the Service Reference.
However I disagree with the statement of "Separation of Concern". I would have AddressChangeService inherit AddressService.
I wrote a couple of simple web methods (as a part of WCF service) that use a couple of (more complex) classes as input/returned parameters. Each web method attributed by [OperationContract], each data class attributed by [DataContract], each data field in the classes attributed by [DataMethod].
On the client side I can call these web methods by adding Service Reference.
All things are fine, but when I create an instance of some of the data classes above on client side, their constructors don't run.
Because it's a little complicate to initialize each instance, every time, I thought there is some way to initialize instances on client side by their own constructors.
Thanks in advance!
Ilan.
Methods exposed on data contracts (including constructors) in your service are only for service applications. Adding service reference will recreated only data structure of your data contract classes because service description is not able to describe logic and logic cannot be serialized.
All classes created with service reference are partial. You can create your own partial class and add your own custom constructors or you can share the assembly with data contracts between your service and client (but it will share all logic added to your data contract classes which is most often what you don't want). Sharing assembly will tightly couple your client and service.
I have an class library called ServiceLayer which acts as a repository for a ASP.NET MVC application This service layer has a references to a WCF Service called ProfileService which contains Profile methods to perform CRUD operations on a database etc.
I now need to allow mobile devices to communicate with my application so I have created another WCF Service called ProfileService. This service has a reference to the ServiceLayer class library and makes calls to it to undertake Profile operations.
Now this is quite confusing as I now have 2 ProfileServices. The first communicating with my database etc and exposing itself to my service layer. The second communicating with my service layer and exposing itself to mobile devices.
What is the best way to name your services in a SOA environment to avoid confusion of which type is which? especially when mapping between types.
I may also want to create another service which acts as an API to users of the system. What would I name this service ProfileAPI?? I know each ProfileService is in its own namespace but this doesnt help with readability when creating AutoMapperSettings or performing manual mapping.
So if anybody out there knows of a good way to name services in this environment it would be much appreciated.
You are looking for a Service Facade
You would end up with a Facade, which is just a specialized interface into your real service. You would define the different services as needed (mobile, users, database)
I am not understanding how my model can be a WCF service. It makes sense when its an Astoria partial class residing on the client that allows remote calls to do persistence calls, but a WCF service doesn't have properties for model fields that can be used to update a data store.
Even if I could factor out an interface for a model/domain object class into a separate assembly, a silverlight project will not allow me to add that as a reference.
How should my ViewModel encompass my WCF calls? Ultimately the WCF will call a repository assembly implemented in Linq-to-Sql, but apparently those entities are not my model in this scenario, my WCF classes are?
Thanks for any guidance on this.
Also, posts I have read to give a frame of reference:
http://development-guides.silverbaylabs.org/Video/Silverlight-Prism#videolocation_0
http://blogs.conchango.com/davidwynne/archive/2008/12/15/silverlight-and-the-view-viewmodel-pattern.aspx
http://msdn.microsoft.com/en-us/magazine/dd458800.aspx
When you create a service reference to a WCF service in a Silverlight project it also generates an interface for that Service, this is similar to David Wynns IFeedService in the articles you listed above. The service reference will also generate proxy objects that represent the objects used by the service (Product, Category etc).
The important thing to note is that the service interface isn't the model, it's how you access the model. Going back to David's example, his ViewModel exposes a list of items (his model), this list is retrieved using the service.
If you're looking to share code between the client and server I'd reccomend looking into something like RIA Services. If this isn't for you then I'd look at a few articles around about sharing code between the server and client (via Add as Link).
Hope this helps