I have a problem using delegates. I have an object that provides some services. Now these services need another (async) service (another object provides that). So two different services require the same (third) service. These two calls need to be handled different in the delegate method of the third service. How do i do that? Is there a design pattern for that?
I would just create some ServiceHandlerObject and register that as the third services delegate. And then just use a different ServiceHandlerObject for each service to provide. But i have no idea if this is "the way you do it".
Related
What is the best way to organize interaction between services in the service layer?
For example, I have document service and product service. In my case products can have their own documents and to manage documents of product I call appropriate methods from the document service in the product service. So, I need to create instance of document service in product service. And I need to call some methods from product service in the document service too. So, each of these services refers to other and I get stackoverflowexception respectively.
Which design solutions should I use to eliminate these problem?
Application Services are supposed to provide external clients an API for executing cohesive business operations. An application service method generally matches a use case of your application.
While an application service operation may require calling another service (eg, the Create Product use case includes the Create Document use case, which can also be called separately), this is not the norm and you should look to make your application services as cohesive as possible. In particular, just because at some point in your business case you start to manipulate another kind of entity doesn't mean you should delegate that part to another application service - in other words, one application service per entity is not necessarily right.
In any case, from your domain it should appear clearly in which direction the dependency between 2 applications services points. In your example, Product Service seems to depend on Document Service - it's difficult to imagine why it would be the other way around.
If you really need a round-trip between service A and service B (which I wouldn't do unless I have no other option), you could try and have the instance of A inject itself into B instead of relying on a DI container to resolve the dependency with a new instance, solving the stack overflow problem - if that's why you get a stack overflow in the first place.
Obviously, circular dependencies are wrong.
You can use shared identifiers to decouple Products and Documents.
Moreover you can orchestrate the service interaction from outside them, in the application: in the ProductService you can have a LoadProducts(ProductIdentifiers[] identifiers) returning an immutable collection of products and in the DocumentService you can have a LoadDocuments(DocumentIdentifiers[] identifiers) returning an immutable collection of documents.
What are the advantages and disadvantages of having more WebMethods in a single Web Service?
If you add multiple web methods to a single web service class, they will all be supported through a single URL (which can make deployment and configuration much simpler). On the client side, when you create a web reference, it will create a separate class for each web service, and than separate methods within each class, one for each web method. So, as you can imagine, it's easier to work with in the client code, as well, when you have a single class with multiple methods rather than multiple classes each containing only one method. That can become a nightmare for dependency injection (DI) (you are injecting your dependencies right? Hmmm?). So, the rule of thumb should be to try to group all the related methods together into a single web service and keep the number of web services as few as is reasonable.
I have created objects that are interfaces to a web service. One typical object would be a "TaskService". When a client uses one of these objects, it invokes one of the service's methods (such as "GetTasks") and the service will asynchronously go off to call the remote web service, and post back the retrieved data via a delegate.
Currently, to use one of these services you have to create it with [[TaskService alloc] init], but I decided it makes more sense to make each service into a singleton object.
Is it common to see singleton objects that hold reference to delegates? My main issue with the design, is that each object, whenever it requires use of a particular service, will have to set itself as the delegate before invoking the service, which doesn't seem quite right to me... What if another object were to set itself as the delegate inbetween you setting yourself as the delegate and invoking the service?
Many thanks in advance!
Regards,
Nick
Imo this is not a good idea for the reason you cited. The Singleton pattern is really for things there are only one of, but it sounds like your app can have need for multiple instances of these services. I think you'd wind up working around this (using an operations queue or some kind of delegate multiplexer) when you really just need to instantiate multiple instances of your service.
When the occasion warrants the use of a Singleton object, I always avoid delegation for the reason you cite. Consumers of a singleton can't know (without some ugly coding) if they're stepping on some other consumer's toes by setting themselves as the one-and-only delegate of the singleton. NSNotifications are a much cleaner tool for the job; any arbitrary number of listeners can consume the notifications without caring who else may be listening.
Delegation works best when there is clear ownership between the classes. Nobody owns a singleton.
Singleton isn't really the problem, you cause the same sort of issues by simply instancing a class and passing it about as a global variable.
As other's have mentioned a queue is a possibility, or when you invoke a task on a service in your Singleton have it instance a TaskRequest object passing in the method and the call back delegate, that way requests can't trample on each other. In fact it would be a good idea to do that with a queue anyway.
The scope of a singleton is entire application. For example: Let consider the example of shopping application the logger data, about the user ID which need to be accessible on different part of application like order, payment, cart etc.
Delegates are used for 1 to 1 communication, for example: You can take as example You have two classes TV and remote control device. You want to change the channel of TV. Delegate methods of TV for changing channel are implemented in remote control device class. So you use remote control device and you change the channel of the TV.
The singleton is used to communicate with multiple receivers, while the delegation pattern is used usually for 1 to 1 communication.
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 calling an external services in three steps: Compose the request, send it and receive the result, extract the result.
Now there are several external services that I will be using, building on different application stacks (SOAP and REST for instance. How would a good OO-design for this situation look like?
My specific concerns are: I could have interfaces for RequestBuilders and ResponseParsers, and a ServiceCaller that would delegate the obvious steps to implementations of the interfaces. But that means one could have a ServiceCaller that builds requests for service A, and expects responses in service' B format.
Whats a good OO pattern for that in general?
You can have a look at the Factory Method. The Create method of the factory accepts the type of the object required (Request of ServiceA) and returns an IRequest interface. All request implementation are required to implement IRequest. Once this layer has been built, you can create the service layer containing the builders for the appropriate Request and Response type.