WCF, inheritance and object graphs

[steinard]

Hi!

I'm reading up on WCF before switching from .Net Remoting to WCF. I haven't been aware of any breaking changes in the new communication technology, but today I stumbled upon this thread (http://forums.microsoft.com/msdn/showpost.aspx?pageindex=3&siteid=1&postid=2910261&sb=0&d=1&at=7&ft=11&tf=0&pageid=0) which kind of got me concerned.

As I have a real domain model containing almost all the complex business logic rules and calculations and thin services that mostly delegates work to the domain model on either side of the network boundary, I'm afraid I have to do some serious changes to the app just to be able to transport data from server to client and vice versa when switching to WCF. Is this correctly understood?

In another thread (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2884951&SiteID=1) a user explains how he solved his problems with WCF (having problem with sharing the same dlls on both client and server side) by creating a custom serializer/deserializer that uses a byte[] as the data object via WCF.

I could be wrong but I'm of the impression that quite a few developers reuse dlls on both client and server side and would need such functionality. Does Spring.Net WCF exporters come to rescue and bring such support out of the box?

Cheers,
Steinar.

[fba]

Isthiscorrectlyunderstood == true

Working on the same project type; well the fact is that WCF is still Microsoft based technology :
Meant to do some brilliant quick and dirty demos and "do-it-yourself" in real world apps.

Well over B2B, it's the frightening SOA that has been victorious over real object distribution.

If your application is not just :
GetWeatherOF(string country)

Most of time, in front of WCF, I feel like back in the 90's where the top of the roppe was writing stored procedure called more or less anonymously by client.

That's exactly where you may find huge similarity between WebServices (WSE3.0) and WCF.

And yes, you will have to share at least the interface DLL with your client and more than his : you will have to find the better way to generate your proxy (web services, I told you, and get the asynchronous proxies working).

The biggest point of pain is that whatever the theorical debate is, that a lot of your business logic is now in your services. (Atomic, like Sp)
Even worst : if you have a client that displaying an object with a lot of business functionnalities (I mean something very tough, not a petshop, northwind, or others concept that let you think you have a business logic) then you will realize that in 2008; client as never been so close to server.

Yes you can implement callback, messaging, but material is hard to find; and implementation is (still) painfull.

But well; there are no magic tools, just poc.

Good look; I've been there (and still stuck in...)

[chrisjsmith]

We gave up on WCF and said SOAP external, remoting internal. Works a treat.

WCF required more work to get it off the ground than anything I've experienced.

[steinard]

Hi!

Next week, after a customer installation, I'll try to use the Generic Remoting project. This project uses WCF to enable remoting (just like the good-old .Net Remoting). Best of all, it is open source. The project seems to be solving all my problems, take a look at it, it is really interesting work:
http://slagd.com/?page_id=16

Even though I'm also using NHibernate, then I will not use the NHibernate.Remote project.

Thanks for the replies, it is good to hear that there are more people in this boat than me...wherever I post I heardly hear anyone complaining about WCF...

Steinar.

P.S The pdf-documentation on Generic Remoting is a nice read, it also gives you some under-the-hood insights on WCF.