Need advice on how to design WCF service

Hi!

I have a question about a bunch of services I work on.

Basically I have 4 stored procedures I will now design a service that will use them. But I am not sure if I really need to create a new service or if I can use an existing one.

The new procedures handle bonuses. Basically you can create a bonus and then add it to a specific user.

There already is an existing user service. So I am thoughtful about if I should add these methods

- create bonus
- delete bonus
- get bonuses

to the existing user service or if I should create a new bonus service.

What is the general patter to use when designing services like this? That have dependencies on other entities in the database.

Other examples are block lists. It is possible to block a user by adding it to a block list. There are three tables in the database that are affected by this.

BLOCK_REASONS

USER

USERS_BLOCKED (FK to USERS and BLOCK_REASONS + comment and date field)

The first table contain all block reasons that you select in a drop down list when you are about to block a user. And the USER table consist of the user to be blocked and the USERS_BLOCKED contain all blocked users along with dates and comment fields.

How should this be designed in the SOA? What services a and methods should you design for this?

kind regards
Henrik

AN update to this with another thought.

There are many different kind of bonuses

- campaigns

- offers

- triggers

etc. And today they have implemented campaigns as a separate service. Is this the right way to do?

My thoughts are... one bonus service would probably be too fat, but then the campaing loses its connection with bonuses.

o/

I asked a similar question here: http://www.vbforums.com/showthread.php?t=561208
Dont know if that helps with your exact situation though..

Hi!

Yes that thread pretty much confirmed what I already suspected.

Now I have another question. Im working on a side project which involves implementing WCF services in a VB.NET client. The developer likes to work with data contracts in this form:

Code:

---

[DataContract(Namespace = "http://test.com")]
    public class Car
    {
        [DataMember(Order = 0)]
        public int? CarId { get; set; }

        [DataMember(Order = 1)]
        public string Brand { get; set; }
    }

---

The problem is that there are about 20 different data classes like the one above, and some of them contain almost identical information, give or take a few properties. Is it a bad thing to try and break out the common properties into a base class and then inherit that class whenever those properties are needed? Or is this a good approach, to design tailor suited data contracts for each possible situation? I am surprised the programmer doesn't use OO here, it seems to be the logical choice.

/Henrik

I dont know of any reason personally why you couldnt just use a base class and inherit it but one thing to consider is that it might make the amount of XML being transferred on the wire larger because it will have to take into account the nested types etc but to be honest unless you are sending a hell of a lot of data then it shouldnt make any noticeable difference (provided you have increased the MaxItemsInObjectGraph attribute anyway, otherwise you might hit the 65000 limit, as I have done several times)

Quote:

---

Originally Posted by MrNorth

Hi!

I have a question about a bunch of services I work on.

Basically I have 4 stored procedures I will now design a service that will use them. But I am not sure if I really need to create a new service or if I can use an existing one.

The new procedures handle bonuses. Basically you can create a bonus and then add it to a specific user.

There already is an existing user service. So I am thoughtful about if I should add these methods

- create bonus
- delete bonus
- get bonuses

to the existing user service or if I should create a new bonus service.

What is the general patter to use when designing services like this? That have dependencies on other entities in the database.

Other examples are block lists. It is possible to block a user by adding it to a block list. There are three tables in the database that are affected by this.

BLOCK_REASONS

USER

USERS_BLOCKED (FK to USERS and BLOCK_REASONS + comment and date field)

The first table contain all block reasons that you select in a drop down list when you are about to block a user. And the USER table consist of the user to be blocked and the USERS_BLOCKED contain all blocked users along with dates and comment fields.

How should this be designed in the SOA? What services a and methods should you design for this?

kind regards
Henrik

---

Put it where it's most logical. You've got your SP which creates bonuses. Alright. Does this SP only create USER bonuses? Does it also create TRIGGER bonuses?

If it does all the bonus types, then that means that the bonus methods are not user.svc specific. They should go into Bonus.svc.

Doesn't matter what tables it affects, the main thing is what its logical 'description' is. It creates bonuses.

For the blocked example, it appears that only users are blocked. So you're blocking... users. You won't be doing anything else with the concept of 'blocking' will you? So this'd be better placed in User.svc.

Quote:

---

Originally Posted by MrNorth

Hi!

Yes that thread pretty much confirmed what I already suspected.

Now I have another question. Im working on a side project which involves implementing WCF services in a VB.NET client. The developer likes to work with data contracts in this form:

Code:

---

[DataContract(Namespace = "http://test.com")]
    public class Car
    {
        [DataMember(Order = 0)]
        public int? CarId { get; set; }

        [DataMember(Order = 1)]
        public string Brand { get; set; }
    }

---

The problem is that there are about 20 different data classes like the one above, and some of them contain almost identical information, give or take a few properties. Is it a bad thing to try and break out the common properties into a base class and then inherit that class whenever those properties are needed? Or is this a good approach, to design tailor suited data contracts for each possible situation? I am surprised the programmer doesn't use OO here, it seems to be the logical choice.

/Henrik

---

Tell me that isn't an actual class from your project...

Anyways, do you mean that there'll be a class Car, and a similar class with the same properties plus one? So you could have Car2 with CarId, Brand and Color?

If yes, then (notice how I talk in if-then-else statements) tell him that it's alright to create a class that totally describes Car, but to leave some properties empty some of the time.

Hi!

No that isn't a class from the project, just an example :D

I had some thoughts about how to do with the "misc" stuff that will change very seldom, like

Countries

Languages

Gender

SI units etc


They are used in many places in the app, but for now they don't load this from the service/database.THey smply create a list of in memory items List<of T> that is used as a singleton throughout the application.

I find the above things not so easy to add to any exisitng service, so perhaps there should be a new service. But hat on earth should it be called? I think there are too few operations to justify a "Global" server for languages and countries...

Perhaps the genders can be fetched from the UserService.

There are often 90 % of the services/operations that are easy to categorize... but these last 10 % should prove most difficult....


/Henrik

As an example, all the methods which are specific to the app/site I'm working on, which would never fit anywhere else and which don't have a logical sub category, do technically fall under the purview of the site itself. So something like "GetAvailableLanguages" would be specific just to the site or app you're working on.

You can lump them together in a service named after the app/site - the VBForumsService. Technically it's not a service that could ever potentially be shared but it's a place for you to put the rest of your operations.