Currently I am creating a WCF service which has to connect to a DAL which, just connects to a database using ADO.net and stored procedures.
The DAl writes its responses from the database to a datacontract which is passed over the wire to the client via the service.
I was reading that this may possibly be the anti pattern 'CRudy Interface', but I wasn't sure as I am sharing the datacontract.
If I am using an anti pattern, can anyone suggest a better pattern to use for the behavior I require?
Well, there seems to be some controversy about the CRUDy pattern and it's pros and cons. At a minimum, I would call a service interface that makes you write this kind of code to use it an anti-pattern (as commented here):
service.CreateCustomer(c);
foreach(Group group in c.Groups)
service.AddCustomerToGroup(c.CustomerId, group.GroupId);
foreach(Person person in c.Contacts)
service.AddCustomerContact(c.CustomerId, person);
Is exposing CRUDy interfaces bad in itself? I wouldn't say so. What's important is to provide an interface which will
encapsulate knowledge about the underlying processes
not be very chatty
It does seem like the CRUD interface anti-pattern, but it would be good to see some interface examples to confirm.
This paper has a really good discussion on designing better service interfaces.
It includes a critique on, and alternative to, the CRUD anti-pattern.
If you have a cruddy use case to implement you will get a cruddy interface, don't sweat it. The anti-pattern is when you implement non-cruddy things in a cruddy way.
Related
I'm writing a client for a REST API for an ERP system(large complicated piece of software). I want to get the design architecture correct now, so I save myself time down the road, hoping you can help. If helpful server side urls are of the format /myServer/v1/someService/someMethod?someParam=x
I started off with a restClient class with public function for all the ERP actions(e.g. restClient->someServiceSomeMethod(someParam)). The restClient knows about authentication, and has private get, post, etc methods. I started with this approach as it's the simplest architecture, although I'm wondering if I should be using inheritance or some other approach(I don't want to overcomplicate but I'm starting to feel like I'm going down the wrong path). For the past 10 years are so I've written mostly procedural code, so I'm a bit rusty on OOP design... Would it be "better" to have classes for each service that inherits the restClient class? The the end code would then instantiate the service object they need then calls the method(someService->someMethod(someParam)? This "feels" like the right way to go, but I'm fuzzy on how I'd authenticate and it's been a long time since I did OOP so would hate to overcomplicate things and get no value out of it.
A good rule of thumb for me is that simpler is usually better.
Inheritance, in my opinion, feels a bit restrictive for this - and you introduce coupling that might cause you pain later. If you build 100 different services and they all share a common super class, but it turns out that 5 of them need to be behave in a slightly different fashion, everything else will also be affected. That could get messy.
Although I don't have sufficient detail to understand all the aspects of your particular scenario, I would strongly consider composition over inheritance - build a RestClient class that can deal with some of the common scenarios (auth, GET, POST, etc.), but instead of extending it, just provide a reference to it to anything else that might require that functionality.
In addition, if there are various 'groups' of common operations (e.g CRUD), why not model those with an interface? Your classes could then implement the interface instead of extending a common super class, giving you the benefit of consistency but without the drawbacks of inheritance.
I have a Component which has API exposed with some 10 functionality in all. I can think of two ways to achieve it:
Give out all these functionality as separate functions.
Expose only one function which takes an XML as input. Based on request_Type specified and the parameters passed in the XML, I internally call one of the respective functions.
Q1. Will the second design be more loosely coupled than the first ?
I always read about how I should try my components to be loosely coupled, should I really go to this extent to achieve lose coupling ?
Q2. Which one of these would be a better design in terms of OOP and why?
Edit:
If I am exposing this API over D-Bus for others to use, will type checking still be a consideration to compare the two approaches? From what I understand type checking is done at compile time, but in case when this function is exposed over some IPC, issue of type checking comes into picture ?
The two alternatives you propose do not differ in the (obviously quite large) number of "functions" you want to offer from your API. However, the second seems to have many disadvantages because you are loosing any strong type checking, it will become much harder to document the functionality etc. (The only advantage I see is that you don't need to change your API if you add functionality. But at the disadvantage that users will not be able to figure out API changes like deleted functions until run-time.)
What is more related with this question is the Single Responsiblity Principle (http://en.wikipedia.org/wiki/Single_responsibility_principle). As you are talking about OOP, you should not expose your tens of functions within one class but split them among different classes, each with a single responsibility. Defining good "responsibilities" and roles requires some practice, but following some basic guidelines will help you to get started quickly. See Are there any rules for OOP? for a good starting point.
Reply to the question edit
I haven't used D-Bus, so this might be totally wrong. But from a quick look at the tutorial I read
Each object supports one or more interfaces. Think of an interface as
a named group of methods and signals, just as it is in GLib or Qt or
Java. Interfaces define the type of an object instance.
DBus identifies interfaces with a simple namespaced string, something
like org.freedesktop.Introspectable. Most bindings will map these
interface names directly to the appropriate programming language
construct, for example to Java interfaces or C++ pure virtual classes.
As far as I understand, D-Bus has the concept of differnt objects which provide interfaces consisting of several methods. This means (to me) that my answer above still applies. The "D-Bus native" way of specifying your API would mean to exhibit interfaces and I don't see any reason why good OOP design guidelines shouldn't be valid, here. As D-Bus seems to map these even to native language constructs, this is even more likely.
Of course, nobody keeps you from just building your own API description language in XML. However, things like are some kind of abuse of underlying techniques. You should have good reasons for doing such things.
What is the proper way to handle polymorphic business objects in a WCF/SOAP world?
It seems to me that SOA and OOP are at odds with each other - to expose a clean WSDL you need concrete objects, typically not even utilizing inheritance. On the other hand, presumably in the underlying system, you'll want to follow proper OO design.
What do people typically do here? Build a set of WCF contract objects, forgoing OOP principles, then convert to and from another set of objects in the actual logic layers?
What do people typically do here? Build a set of WCF contract objects, forgoing OOP principles, then convert to and from another set of objects in the actual logic layers?
Yes.
The way WCF serializes things ends up putting a lot of limitations on what you can and can't do with the contract objects. What you can't do ends up being "most anything useful".
I've found it makes things much clearer if you think of the WCF-contract objects as just a data transfer mechanism. Basically like strongly/statically typed XML.
Instead of converting your business object to an XML string (and back again), you convert your business object to a WCF-contract object (and back again), but it's otherwise similar
After reading the Thomas Erl library, I came to the following conclusion:
Think of the WCF Contracts/SOAP Message as simply a message that the Services use to communicate (don't tightly tie that to Objects in your code).
You can then use OOP to design a code-base that gracefully handles those messages using common OOP techniques.
You use an abstraction (interface type) annotated with WCF attributes in order to define your Service contract.
This is both depending on abstraction, which is according to OOP, as well as defining a service endpoint, which is SOA.
In general, if you find that you are getting business objects with dependencies, you should consider pulling such dependencies up to the service business layer as opposed to inject dependencies into the business objects.
The service business layer will then act as a mediator acting on both the WCF service proxy as well as the business objects. As opposed to having the business objects acting on the WCF service proxy.
All great comments on this topic! I'll add my vote to the notion of an adapter for mediation between your service orientation and object orientation. I also like Thomas Erl's approach where in his service model he introduces the notion of "application services" and "business services." These are the way to go for your integration points with your specific application/business environment (i.e. your object oriented and component oriented framework/API). This way should result in much better composability and thus capability, for you enterprise framework gurus out there.
I am developing a WCF web service which has become quite bloated. What techniques do you use to split up the implementation of the contract?
Well you have a couple choices:
First, you could leave it all in one class, but split up into different files using the partial class feature of C#.
Second, you could have the main service class just pass requests off to one of a number of other actual classes that are organized logically.
A third alternative is to consider refactoring to reduce the number of operations you have. Is there actually a use to all of the methods you're exposing?
Finally, you could always split up the service into multiple WCF services.
It's hard to answer your question if you don't give any more information.
Do you mean that your service interface is bloated, or the class implementation? It's hard to answer well, if I don't see the code, or have no other information, anyway, I'll try:
Notice that WCF service is basically just a regular class that implements an interface and has some attributes on its methods. So all the other good OO design rules apply to it. Think about what it does, does it have really single responsibility, if not try to outsource some of that responsibility to other classes that your service depends on. If you need a non-default constructor, use IInstanceProvider to create the service class, and supply it with its dependencies (or if you use Windsor Container use WCF Facility).
If you really want to you can streach your inheritance chain, and move some of the code to a base class. I don't do it, however and always prefer to use composition over inheritance.
Inspect your service contract, and think about how cohesive it really is. Maybe what you should do is to split it, into few smaller, more cohesive services.
We're using about 7 services at the moment. There quite large.
Does anyone have any experience with the single responsibility principle and WCF services? Does this mean that you'll end up with lot's of small contracts? If so, how do you manage these in your application?
I think you are confusing single responsibility with interface segregation.
From the client/service interface perspective, you should keep your contracts lean and mean. See below for an example of that.
On the SRP side of things, that should be entirely internal to the service implementation and the client should not be aware of this. If you service code is too large, split it up into classes. Then have your service code, at least initially, act as a facade and forward all the calls to the relevant objects. Later on, you have the option of spliting your service into multiple services. But be aware, that SOA and object oriented design, although overlap, are separate and have different requirements.
Interface segregation example: We have a service here at work that we use to do various functions on some business objects. The original service had one interface. As it grew, we realized we had three family of methods: data object persistence, business updates, business analysis. We split up into three contracts. Our client/service implements all 3, so the only thing we had to do was split the contract into three and setup two additional endpoints in our WCF configuration. Very simple.
Hope this helps.
I would suggest you listen to this podcast on the hanselminutes :
SOLID Principles with Uncle Bob - Robert C. Martin
It would help understand things better. . .
You could apply facade pattern for the web service that interface with the client, and in your implementation code you can apply single responsibility to make it maintainable.