|
if you dont know let me know
dev
|
|
|
|
|
How many different ways do we have to tell you that sending a DataTable is not a good idea? It's just too big, even if it's empty!
Create your own objects to hold your data plus an IEnumerable collection to hold them. Then you can serialize that over the wire with minimal overhead.
|
|
|
|
|
you don't know you sh*t
dev
|
|
|
|
|
Voted to remove message. Too bad I can't vote to remove user...
I already told you how it's normally done. If you want ot continue to bang your head against a wall trying to do it the hard way, fine. Don't let me stop you.
|
|
|
|
|
Dave Kreskowiak wrote: Voted to remove message. Too bad I can't vote to remove user...
why don't you ask babe(and start learning how to wire down a DataTable)
dev
|
|
|
|
|
Why should I, when I can do it faster and more efficiently by NOT using a DatTable?
|
|
|
|
|
I wouldn't send a DataTable. I would normally send a custom collection of objects.
|
|
|
|
|
Use a strongly typed object that WCF can expose easily, and that can be recognised by more than just .NET.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
|
The first article you link to there is interesting because he actually advises not to send data as a DataTable because it is slow. He gained a six-fold performance increase by converting to POCO objects (an IEnumerable of type MyData in his example) and using a DataContractSerializer to send.
|
|
|
|
|
Just because you can transmit something as a datatable doesn't mean you should. Think about it this way - would you send your house through the post, just to send a letter that's on a desk? The DataTable infrastructure, in this case, is your house and the letter is the actual data you are trying to transmit.
The bottom line - a DataTable is too heavyweight an object to be a useful transmission mechanism; go for straight POCO instead and you can tune it to be as efficient as possible.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
i think advise to first convert to csv will work fine but i'm not too keen on writing the extra code just to juice the extra performance (presumeably non-significant) when the whole deal is wired within the almighty corporate intranet - we'd rahter wait till users moans about performance before we do this (besides, this is not the bottleneck at the moment, our primary being sql not clustered)
this said, curious, how much overhead with DataTable - the initial overhead, and per-row overhead (We've no time even to test this out... in fact we alrteady built this wiring DataTable as byte array), any experience to this end? is it appreciable?
dev
|
|
|
|
|
devvvy wrote: any experience to this end
Yes.
devvvy wrote: is it appreciable?
Yes.
devvvy wrote: we'd rahter wait till users moans about performance before we do this
Trouble is - that costs more to fix. It's always more expensive to fix problem code later than sooner - changing from a DataTable later on will cause you all sorts of problems because you have other code that relies on the DataTable.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Thanks - I'd just wire DataTable over wcf as it's already done. But build your wrapper around it so client code don't touch the later directly and change (wired as csv instead but delimitors can be a headache and also conversion and casting overhead ... need justify that as well) can be put in place later on underneath wrapper layer.
Just a thought, WCF is successor to asmx so definitely will choose WCF over asmx. What about socket? If interop/security/transaction/reliability all not *required* (think only WCF service we're using now is async call back- which really can also be easily replaced), would you think socket being a better choice for large data transfer over the wire?
dev
|
|
|
|
|
Why not use Tab separated values or some other simplified format? DataTable is a very heavy object and serializing it would give you significantly more bytes to transfer. And from my experience Excel is pretty dumb when it comes to things like data types, so all of that info from the database would probably be lost in translation anyway.
|
|
|
|
|
That's another approach I've suggested to our developer, but entails more work. Besides, this is local intranet app, so bandwidth isn't a problem.
This is not transfering to/from Excel however, it's a WPF app.
dev
|
|
|
|
|
Hi All,
I'm getting some requests to port an application I've built using WPF/C#/SQL Compact to the Mac platform.
My understanding of the general tasks to achieve this are:
Re-write the whole UI (No WPF Support in Mono)
Replace all database access to use MySQL or other DB
The rest of the C# code is targeting C#3.0/.NET 3.5 SP1 so I'm guessing that an absolute stack of this will need re-writing as well as Mono is more or less .NET 2.0 compatible. I'm just trying to get a feel for the total effort that would be required to do this. I keep coming to the conclusion that it would be more or less a complete re-write from the ground up which is kinda daunting at the moment.
Anyone performed a similar task that can give me a bit more insight?
Cheers,
|
|
|
|
|
Jammer wrote: as Mono is more or less .NET 2.0 compatible
Mono is completely compatible with 2.0, and 3.5 is largely supported to. A better comparison with Microsofts' .NET can be found here[^].
Most popular topics on Mono can be found here[^].
I are Troll 
|
|
|
|
|
WPF can't be ported to Mono because it relies on MS DirectX for rendering  .Silverlight could be partially ported to Mono using Moonlight platform.
Life is a stage and we are all actors!
|
|
|
|
|
Hello
SilverLight 4 is a good choice for you. The Out Of Browser -aka OOB- has major improvements. I did an application for Mac this way in SilverLight 3 but the experience were't rich. Two major improvements that could have saved me a lot of trouble are the elevated permissions and the printing support.
Also porting your WPF to Silverlight is a bit easy as both rely on Xaml and Silverlight is just a subset of WPF. As for the database; the typical solution is to put your database on a windows server and communicate using services. If your program is a stand alone and this is not an option you can use some of the embedded DB engine. I don't remember any now but I remember I saw a few names to use back when I made my app.
If you use LINQ and your data access isn't huge or demanding your can switch your (LINQ to SQL) to (LINQ to Xml) and store your data as an Xml file.
P.S.
Make good analysis on the OOB in SilverLight 4. There could be some features in your program not covered.
Regards ![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
If your program is a stand alone and this is not an option you can use some of the embedded DB engine. I don't remember any now but I remember I saw a few names to use back when I made my app.
OS X comes with SQLite "built in", perhaps this is a possibility...
|
|
|
|
|
The mono project has a tool named Moma which is designed to help you figure out
what is missing from mono for a particular project you want to port.
Run the tool on your current implementation and you should be able to find out
what is missing from mono.
Moonlight has full support for Silverlight 2.0.
Hope this helps.
---
Adar Wesley
|
|
|
|
|
Haven't done it, but the Mono site has an analysis tool that will help you figure out how much effort is needed. It basically checks the compatibility of the BCL calls with what is available in Mono.
|
|
|
|
|
You can consider using the following technologies on Mac:
1) Silverlight 4 as a replacement for WPF (the most closest approximation though not 100% complete)
2) SQLite as a replacement for SQL CE (Mono has good support for SQLite)
3) In this case, you will need to re-design your app to support multiple layers (DAL/BLL exposed via WCF - it is partially supported by Mono, specifically for Mac), UI layer running on Silverlight.
This is what I would do if I were in your shoes.
|
|
|
|
|
Is it an option to use a VM?
You could run the app in a VM hosting Windows in 'integrated' mode (or whatever its called) and the app will appear to be running 'like a native app' (i.e. without being inside the VM's virtual desktop). I think VMWare has a Mac version; Parallels is the other major VM for the Mac.
If its politically acceptable to the client to do this, it might be much cheaper (VM license + Windows license + small amount of work) to go this route than the porting route. Of course, there are maintenace burdens once you have a VM that hosts something of importance...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
