Custom processing of CSV file via WCF_问答_开发者

开发者 https://www.devze.com 2023-01-09 19:08 出处：网络

I have a project whereby I have a WCF service that I basically want invoked whenever a file is dropped in a certain directory. I\'ve got the basic custom transport channel logic that I saw published o

I have a project whereby I have a WCF service that I basically want invoked whenever a file is dropped in a certain directory. I've got the basic custom transport channel logic that I saw published on the web that deals with transport over a file. However, there's another point, the content of the file itself. The file is going to be a comma-delmited file of data. For each line in the file, I want a specific method to be invoked on the service. This is the part I am having trouble with.

I do understand that part of this will involve a custom MessageEncoder. Here's my back-of-the-napkin design. The encoder will receieve a stream of data (the file). It will read one line from the file and create a Message from it (that part I'm still a little clueless on). Then, the fact that the Stream has more data to read should tell the file transport channel to read another messa开发者_如何学Cge from it.

Am I on the right track? The other question is how my encoder should handle buffered calls. I get in an ArraySegment by value, so the only thing I can think of is to modify the incoming array (I can't just manipulate the offset, it won't get back to the original caller).

Thoughts? I know this is a bit of a ramble.

You can't do all that work in the MessageEncoder, because WCF has a strong one-message-in/one-message-out bias at that stage. Basically, you're likely going to have to put both your channel and your custom encoder to work together.

What I'd likely do to keep it simple would be for the transport channel itself to pick up the file, open it and read one record at a time from it, then produce (through the encoder) one message at a time to satisfy one receive() call.

As for how to deal with buffering, that's usually a drag, but what those sizes passed to the encoder are for is basically to allow you to set a hard limit on the maximum size of any buffers allocated (so that you don't even try to process messages too big). That's not really a problem, directly, if you use the streaming interfaces, however.