I have a WCF-based, C# CRUD REST api that works on Schedule objects. There are methods for creating, updating, deleting as you'd expect.
My problem is that the Schedule object contains a TriggerInfo subobject. If you just call the constructor, you're really calling the constructor of a proxy, and the real constructor is never called, so the subobjects are not initialized.
The proxy that WCF emits has TriggerInfo as a field but it's always going to be null because the constructor logic in the "real" class is never called.
In other words, when the client creates a C# 'Schedule' object, it's really creating a proxy of the real Schedule class, and the proxy knows nothing about having to init anything!
So in this chicken-and-egg situation, who creates the C# 'Schedule' object that the client can "fill out"?
I thought the C# client could create a Schedule object, fill out all the properties and pass it to the CreateSchedule() api and it'd work. Not so easy!
It'd work if I made a big, flat monolithic class where all of the TriggerInfo properties were properties on the Schedule object instead, but it's not very tidy, especially if you have multiple subclasses.
I could have a ScheduleFactory object exposed on my API that knows how to create one, but I don't know if that's a valid approach!
Don't create Schedule object client-side if it needs any nontrivial initialization - just add a New or Create method to your WCF service and do it server-side. Alternatively, you can use new Schedule() client-side, get a new proxy instance with a lot of null properties and fill in these properties with sensible default values server-side in Save method.
Related
Is there a pattern or recommended method using ASP.NET MVC where I could be editing one object, and need to create a related object on the fly, (which may need another object created on the fly)? Perhaps a library/ jQuery combo package that makes this easy?
Let's say I am in a page called JournalEntries/Edit/1234 and I realize I need to create different Account object for the JournalEntry object... and maybe that Acount object needed a Vendor object that didn't yet exist. I wouldn't want to leave the page and lose everything that was already done, but maybe nest creation forms and pass the state to the parent window when the object was successfully created so that the workflow would be, essentially, uninterrupted.
Does such a thing exist, or are the business requirements too vague and variable to make that a realistic creation? Are there any pitfalls or issues I would need to worry about, building this sort of model?
You could consider delegating creation of the object (and its dependencies) off to a business service, which would in turn use a unit of work and repositories to create the object in the data store. The business service would return the ID of the newly created object if it could create one successfully.
Now you can create a controller action which would invoke the business services. Your front end code can call the controller action via ajax when you need to create the dependent object.
Since above approach is un-obtrusive, your workflow will not be interrupted and you wont need any special library other than jquery
The short answer here, apparently, is "no"... no such library or pattern exists at this point.
I have changed a former WCF one-way service to a duplex service so I can implement callbacks.
My actual problem is since that change, every piece of code that instanciates the service proxy needs to be modified to pass an instance context as parameter into the constructor.
There are many, many places in a few different projects that make use of that service. Everyone of them is now broken.
Will I be forced to go back in every proxy instanciation and pass an instance context into the constructor ? Can I avoid this ?
Simply speaking - no you cannot avoid this.. Presumably you need the duplex service for one WCF call to be able to callback... I would probably just create a separate method on the interface rather than changing the existing one so that you don't break the contract between service and client.
I have a large app which uses COM via .net remoting to call from the web tier to the middle tier.
It's quite slow to startup and to run when in this mode. Both sides of the COM boundary are our code.
I'd like to be able to (optionally) run it in a single process.
Quite a bit of the behaviour relies on calls to ServicedComponents having all their arguments serialized, and that changes made to the objects inside the components don't leak out unless the argument is a 'ref' argument.
My current plan to force this two-process app into a single process without needing to change too much code is by using a fake middle tier boundary with custom .net remoting.
If I change all the:
class BigComponent : ServicedComponent {
...
}
into
[FakeComponent]
class BigComponent : ContextBoundObject {
...
}
Then I can write a custom ContextAttribute to fake the process boundary and make the arguments serialize themselves:
i.e.
[AttributeUsage(AttributeTargets.Class)]
public class FakeComponentAttribute :
ContextAttribute,
IContributeServerContextSink
{
... lots of stuff here
}
As per http://msdn.microsoft.com/en-us/magazine/cc164165.aspx
Now this works fine, so far, and I can intercept all calls to methods on these classes.
However, I can only view the IMethodCallMessage.Args in the IMessageSink.ProcessMessage call -- I don't seem to be able to replace them with objects of my choice.
Any time I change entries in the IMethodCallMessage.Args array, my changes are ignored. From what I can tell in Reflector, this interface is a wrapper around a native object in the runtime itself, and I can't write to this object, just read it.
How can I modify the arguments to method calls in .net remoting?
Do I need to implement my own Channel? Is there a "local" channel tutorial out there I can crib from?
My aim is to have these Components act like remote objects (in that all their args get serialized on the way in to the method, and that their return value is serialized on the way out), but have the remote endpoint be inside the same process.
I have not found a way to edit the argument array as it passes through the IMessageSink.
In the end, I had to make the argument object classes aware of this issue, and implement a new interface IFakeRemotingAware. This allowed the complex object arguments which exhibit the pass-by-val behaviour due to serialization/deserialization when using remoting to simulate that behaviour when using fake remoting.
The interface has two methods: EnteringFakeRemote which causes the object to cache a local copy of its state, and LeavingFakeRemote which causes the object to restore its state from the cache.
I've got a situation where I have several web services that I need to consume. I need the ability to perform custom actions in the constructor of the proxy before any calls are made (assigning the configured URL, assigning the SOAP header, etc.).
My first solution is to create a child class that derives from the generated proxy, then make those actions in the constructor of the child class. That way, app code can call the constructor of the child, and get a valid proxy that has the stuff I need.
I'm trying to prevent the app code from calling the constructor of the generated proxy, so people don't accidentally instantiate the proxy without doing my custom stuff. My first thought is to move the generated code into a separate assembly from the child, and make sure the app code only has a reference to the child assembly. This works for the most part, but...
The services contain complex types, defined in the proxy. I need the app code to reference these classes, which means the app code needs a reference to the base assembly anyway, which means they now have access to the generated constructor.
I've tried an overly-complex solution of wrapping each of the generated complex types in an interface, and then hiding the real calls and replacing them with copies of the object as the interface type. This worked once or twice, but it gets ugly really quick.
It seems that the only way I can have everything I want is to remove the public constructor of the generated proxy, and replace it with a protected constructor, then allow a reference to this assembly - they'll be able to work with the complex types, but won't be able to call the constructor. My problem is that the only way I can think of to do this is to manipulate the generated code to change the constructor.
Any ideas? I'm using WSDL.exe to generate the proxies, and there's no option there to hide the constructor. Is there another way that I'm just missing? I suppose I can write a tool to automatically modify the proxy immediately after it's generated, but that just feels ugly to me.
Thanks
Are you stuck using .NET 2.0? If not, then you shouldn't be using WSDL.EXE. You should be using SVCUTIL.EXE or "Add Service Reference".
Instead of creating a derived class, you should create your own wrapper classes, which use the proxy classes. One would use something like MyWrapper.CreateProxy(), which would return a properly-configured instance of the proxy class.
BTW, WSDL.EXE creates proxies using the legacy "ASMX" technology, which has no ability to use the types from the service.
I ended up going with modifying the proxy generated code to make the constructor protected instead of public. The call to WSDL.exe was handled in an automated project already, so it wasn't that big of a deal. This was really the only way I could get everything I wanted.
Instead of doing that, why can't you override the GetWebRequest method? It will be called before the service method call anyways.
If you have added a service reference, implementing message inspector will do same thing.
How to dispose objects in a Singleton WCF service? I am using Entity Framework (3.5) and returning a bunch of custom POCO objects to the client. The service needs to be alive as it provides cross-client communication and hence Duplex binding is used. I would like dispose all the POCO objects created once they are serialized to the client.
As the session and hence the service is still alive, it looks like Framework is not doing any Garbage collection on these objects and over time the service is crashing with "Insufficient Memory" like error (after about 2GB).
I don't think dispose can be called before return statement, as the objects are not yet serialized by then.
Please suggest a solution.
Thanks in advance.
First, do not use singleton service, why, well your question is the answer.
As I see it your service should be a per call instance managed and the callback channels should be managed on another class or as static member in the service class.
Second, try to see if you keep reference to the poco's you return to client, Cause GC cleans unreferenced stuff. So if you find the reference just assign those member with null and GC will do the rest(you have nothing to worry about method variables).
I think you're on the wrong track here; if your objects are POCO, do they even implement IDisposable (not sure why you would for a POCO class). My guess is you've got something else that is chewing up your memory. Possibly your singleton service is just living too long and collecting too much crap; you might want to look at a different service model. Maybe an instance per session or something like that.
One thing you could do, however, is rather than serializing your POCO objects directly create very simple 'messaging' classes that have only the properties you want to serialize and send those instead. You could copy the properties to your message objects and then dispose your database objects immediately.