WCF Multiple Service Contracts

I'm brand new to WCF and I was wondering how to architect my design. I want to expose methods for all my domain objects to be able to get and set their properties. I have them all split up into开发者_Go百科 their own interfaces. i.e)

public interface IGroupDAO {
    IEnumerable<Group> FindGroup(string criteria);
    Group GetGroup(int groupID);
    IEnumerable<Group> GetSubGroups(int groupID);
    List<IDMatch> UpdateGroups(Group[] groups);
}
public interface IUserDAO {
    IEnumerable<User> FindUser(string criteria);
    IEnumerable<User> GetSubUsers(int userID);
    User GetUser(int userID);
    List<IDMatch> UpdateUsers(User[] users);
}
... etc

From what I understand if you create an end point for each service contract the end points are all segregated right ? The reason I ask is if I wanted to create a transaction that housed all the update statements. i.e)

CreateTransaction();
UpdateGroups(groups);
UpdateUsers(user);
CommitTransaction();

would this be possible to do if I exposed all the service contracts separately ? I want to ensure everything is saved before I commit the transaction so I don't leave my data model in an unknown state.

One idea I had was to aggregate all the interfaces together

public interface IAppDAO : IGroupDAO, IUserDAO {}

This way I could expose everything and easily reorder the updates on the service if needed. So if I had to save a sub set of groups before the user then I could save the rest of the groups or any weird cases like that. I would like to keep all the save logic in the service so the client can be dumb and say "Save all of this stuff", then on my commit the service should reorder everything properly and update the proper sources.

Let me know if I'm crazy or if I could architect this a different way ?

Thanks

p.s) I do have one more question... if I expose multiple service contracts I have to connect to each one individually right ? So I would have to authenticate to each one separately ?

You actually don't need to expose your DAO interfaces as service contracts. Define a single service contract interface which will contain for example a method Update:

[ServiceContract]
public interface IMyServiceContract
{
    [OperationContract]
    void Update(User[] users, Group[] groups);
}

public class MyService : IMyServiceContract
{
    private readonly IUserDAO _userDao;
    private readonly IGroupDAO _groupDao;
    public MyService(IUserDAO userDao, IGroupDAO groupDao)
    {
        _userDao = userDao;
        _groupDao = groupDao;
    }

    public void Update(User[] users, Group[] groups)
    {
        _groupDao.UpdateGroups(groups);
        _userDao.UpdateUsers(users);
    }
}

You may implement a custom IOperationInvoker and plug it into WCF to handle transactions.

I wouldn't go so far as to say 'crazy'. I would say you should do some reading about OOP and SOA and perhaps, um, read some source code for projects that do this sort of thing.

Your plan indicates to me that inexperience with WCF is not the salient issue here. You need to obtain a more fundamentally sound grasp of system design or you will find yourself chasing ghosts.

Something to search for that is relevant to your question, when you are ready, is Session-Per-Request.

Have fun.