Are there two or more ways to couple and decouple the service type and service contract?
The book I'm reading speaks of coupling and decoupling in two different ways. Am I reading it wrong? I can provide examples but I'm trying not to over complicate this post.
1) She speaks of coupling and decoupling the service contract and service type. Basically coupled is when you don't define an interface for the service contract. You just use the type. Decoupling is when you use an interface as the contract and a type to implement the interface.
2) But she also seems to talk about coupling the service contract (interface) and service type (class implementation) by placing them both in the same assembly. I understand assembly to mean class file (.cs).
ARe both of these coupling/decoupling scenarios? How do you differentiate between the types in conversation? Do they have different names?
I can copy the actual text if necessary. But i was hoping you might understand without all the extra reading.
Thanks!
Related
Diagram below depicts how
producer creates new messages/requests filling data members,
messages are serialized,
sent to consumer,
dserialized,
Consumer invokes virtual function - uses polymorphic behavior of base class reference.
This article discusses a similar question.
But I need to separate DTO (in DataContract.DLL) and some implementation (App.EXE) linked to this DTO within the same class hierarchy (I try to avoid introducing another family of classes like RequestProcessors).
Implementation should be overridden in a different assembly than dll with definition of DTO/message - this dll should be lightweight - used by different teams. Therefore I can't refer to derived class in attribute [KnownType(typeof(SomeData))] like in mentioned article. I don't want to include method implementation in DataContract.DLL.
How to implement polymorphism in hierarchy with serialised classes (DataContract messages) where DataContracts and implementation are separated in different assemblies? Is it possible?
I didn't find the way but C# is not my primary language. I see that producer should not depend on Consumer.EXE but should create most derived class. So, all classes should be introduced in DataContracts.DLL. Partial class definition likely are not cross assembly.
Maybe multiple file assembly will work? Maybe extension method are closest approximation.
Updated (quotation from article):
DTOs that are decorated as DataContract classes are real objects. They can have methods in them, but the methods are not part of the serialization process
How to implement polymorphism in hierarchy with serialised classes (DataContract messages)
"Polymorphic data contract " is an oxymoron.
Data contracts are DTOs (Data Transfer Objects) implementation for WCF.
WCF clearly separates data (data contracts, DTOs) from behavior (services).
Do not mix them.
In other words:
don't try to implement polymorphism in DTO hierarchy;
do not add any behavior to DTOs.
I try to avoid introducing another family of classes like RequestProcessors
But you shouldn't!
This is natural approach for service-based solutions, and this is not about WCF (SOAP) only. E.g., REST (ASP .NET Web API in case of .NET) does the same.
Moreover, service-based way suits well for business-logic implementation inside applications, because it perfectly fits Dependency Injection containers.
Do implement some IRequestProcessor hierarchy - this is the right way to go.
Note, that linked question is about inheritance, but it is not about behavior inheritance. IMO, term "polymorphism" is misused there. You can (and often should) derive one data contract from another, but you can (should) derive data, not behavior.
I'm trying to do dependency injection throughout the app tier and am running into a scenario I'm sure others have seen. There are some 3rd party web services that we consume and the clients were auto-generated with a base class. The clients do not have an interface and the data types are in the same file/project.
The obvious problem is if I want to do unit testing I'll need to mock the service. I'll need to extract an interface and move the data types into a "contracts" project that is available to both real/mock clients. However, the next time the client is auto-generated that work needs to be redone. Creating a proxy at runtime wouldn't help much because then we would have to manually create the interfaces and data types from the WSDL. Is there a better way to handle this?
Extracting an interface from the implementation is not going to help you much anyway, as it's going to be a poor abstraction.
Interfaces should be defined and owned by the clients that consume the interfaces. As Agile Principles, Patterns, and Practices explain, "clients […] own the abstract interfaces" (chapter 11). Thus, any attempt to define a data-centric interface like extracting interfaces from auto-generated web service clients is bound to cause problems sooner or later, because it's violating various SOLID principles like the Dependency Inversion Principle or the Interface Segregation Principle.
Instead, your client code should define the interfaces that they require. Then you can always implement those interfaces with the auto-generated web service clients. If you've used Microsoft's tooling (Visual Studio, wsdl.exe, etc.) the relevant auto-generated class should already be a partial class, which means you should be able to add behaviour to it without touching the auto-generated part of it.
I am trying to hold to the DRY principle in developing WCF services for our application, but I seem to be going down a lot of rabbit holes. My original idea was to have an abstract base class to hold code common to all services, and have derived classes for each concrete service, but cannot seem to get VS2012 to play nice.
Whenever you create a service class, it INSISTS on putting the contract (interface) and implementation classes in the same project, and trying to pull those apart seems to hose up the wiring that VS has done under the hood, so then things break.
I guess all my years of "classic" OO design are getting in the way, I wanted to have the concrete services derive from the interface class AND the abstract base class, but I'm not having a lot of luck. I have found questions/blogs on having polymorphic DATA types used by services, but have not found examples of polymorphic SERVICE types. Can anyone point me?
Thanks,
Peter
UPDATE: Perhaps I am over-thinking the whole thing, I am actually NOT trying to have inheritance for OPERATIONS since a composite approach would make more sense, I just want to keep common code in one place (obviously...), and the whole "static helper class" approach always feels "dirty" to me, kind of defeating the whole OO approach...I am hoping I can simply have the contrete service classes inherit from an abstract base class that is NOT necessarily the implementation of any particular service contract, but is just a way to keep the code DRY...
ALSO: I am trying to use the Template pattern for the service classes, since the overall structure of the services is so similar (devil is always in the details...)
You can separate the interface classes and implementation classes into different projects. One easy way to do is to create the projects manually and write/copy the code as you would for any .NET OO solution.
The following is a set of samples provided by Microsoft...
http://www.microsoft.com/en-us/download/details.aspx?id=21459
You should be able to dig into the samples and find one that meets your requirement.
I'm trying to put together a very granulary loose coupled design.
But I can't decide how to handle common definitions.
Right now I seperate concerns by adding it as an external dll. Through injection and interfaces my domain can use my business logic without knowing the implementation.
The problem I'm having is that for all my components to be loosely coupled, they need to implement the same interfaces. My solution was a seperate project (dll) with just all the definitions.
This started out well, but seems to become bloathed and chains all code together on this one dll-dependency.
What's the most pragmatic way to go about ?
Thanks!
EDIT
Sorry I think I initially misunderstood your question. So you have one assembly which contains your interfaces and you have your implementations in other assemblies using DI to create your dependant objects. I tend to create a core assembly in my application which holds the main behaviours of the app (smart entities, enums and interfaces). This assembly depends on little but is heavy depended on by the rest of the application. Check out this project as an example - whocanhelpme.codeplex.com. You could call this core bloated but it, by definition, needs to be very rich.
You might find that many of your abstract units follow common design patterns. Here is a site that gives a good description of each one - you may be able to derive names from these (Observer, Factory, Adapter etc.):
http://www.dofactory.com/Patterns/Patterns.aspx
I would say, that the layer should only know about the next layer and its interfaces, so it is fine to place interfaces along with their implementations and then add references between layers (assemblies) in the chain.
You can configure DI using bootstrapper pattern and resolve through the locator. Regarding cross cutting concerns like logging, caching ect there should be separate assembly referenced to each layer. Here you can also employ contracts and in the future perhaps replace these cross cutting functionalities with another assembly implementing the same contracts.
Hope this helps at least a bit :)
I was wondering if it was better in WCF to use multiple operation contracts or to have only one operation contract with a polymorphic data contract.
Let me give you a small example :
[OperationContract]
action1Answer action1(action1data a);
[OperationContract]
action2Answer action2(action2data a);
or
[OperationContract]
actionAnswer action(actionContract a);
Action contract would be an abstract class which both action1Contract and action2Contract will inherit from. The action contract would specify the do() member function in its interface which would have in turn to be overloaded in the child classes
Personnaly I find the second approach to be more intersting as it allow you to nicely encapsulate the data and the action in the derived actionContract and in turn makes it easier to add new actions. But It's the first time I'm using WCF so probably you know better!
This question borders on the edges of the Holy Wars of OO polymorphism and SOA, but I'll provide my two cents:
When you're considering developing a service layer, it should be clear to the end consumer of the service what to pass in and what to expect; approach 2 doesn't handle that well. (Also, when doing SOAP with WCF and then loading from the wsdl in other .NET projects, it doesn't properly mark abstract classes, nor do interfaces get transferred. WSDLs have no way of describing a non-instantiable base class, it seems.)
Though, I must admit, I think the second process is great using the KnownTypeAttributes (as I see just now marc_s has posted) - I've used it myself when allowing for unknown future requirements.
I agree approach #2 looks better - from an OOP standpoint.
But: SOA/WCF and polymorphism typically don't match too well - SOA (at least when doing SOAP based calls) needs concrete classes that can be expressed in the WSDL/XSD that defines your service.
You can use derived datatypes based on a common base type - if you do, you'll have to look into the KnownType attribute (or ServiceKnownType) to signal to WCF that you might be returning something else than the operation contract actually says it will.