What we’re wanting to do is use typical POCO objects over a service. Now, I know that services are really made to provide functionality ala carte, but really, the issue that we’re trying to address here is achieving the same usability that you get with a class library (POCO functionality like attributes, constructors, and behaviors in a compiled library) along with the benefit of having a centralized, reusable assembly that is called “on the fly”. That way, we can build the libraries, and re-deploy it to ONE location and all apps that reference it will be updated.
It would seem that WCF doesn’t really support this, and I can understand why. In most cases, people tend to scoff condescendingly and ask “why would you do that?”. Well, I’ve answered that here. So what I’m really asking is where should look into to achieve this sort of “central class library”? I don’t feel like services are the answer, but I need to achieve a central class library that can be accessed like a service. This way, an update of that class library would transparently affect all applications that reference it vs. having to re-reference it in every app. Does this make sense? TIA
UPDATE:
Just thought about it. Would it be stupid to just add the assembly to the application server’s GAC?
What I ended up doing is creating a class library that wraps around the web service. all business logic stays in the class library while all data access is done through the service. this hides any complicated ping ponging from client side programming and makes for some pretty easy and clean pages.
on a side note, it turns out that objects created in the WCF service still support abstraction so I was able to leverage that a bit. I created a naming convention for service data transport objects with matching class library objects. the library objects have the same property names as the service object, plus anything else that they need to perform (i have them separated by regions).
so i think this is more proper usage of the service and pretty much solves my problem. Quite a bit of extra work, but now we have a more flexible architecture that is both loosely coupled and highly cohesive.