Java/NET Dataset
-
I am interested in hearing how the .NET Dataset / Java serialization/deserialization is handled in the increasing number of .NET UI/Java mid-tier architectures. I'm working on numerous applications for such an architecture and would prefer to retain the advantages of the DS at the client without impacting the "back-office" architecture. I'm very concerned regarding Datasets with multiple tables and relationships than a simple 1 table instance. I'd especially like to know packages used, custom work performed, gotcha's, performance, bandwidth, etc. if the many experts here don't have an answer, then it doesn't exist yet. Nothing is impossible, we just don't know the way of it yet.
-
I am interested in hearing how the .NET Dataset / Java serialization/deserialization is handled in the increasing number of .NET UI/Java mid-tier architectures. I'm working on numerous applications for such an architecture and would prefer to retain the advantages of the DS at the client without impacting the "back-office" architecture. I'm very concerned regarding Datasets with multiple tables and relationships than a simple 1 table instance. I'd especially like to know packages used, custom work performed, gotcha's, performance, bandwidth, etc. if the many experts here don't have an answer, then it doesn't exist yet. Nothing is impossible, we just don't know the way of it yet.
I don't think the dataset was really designed to do that. .NET 2.0 datasets are greatly improved over the .NET 1.1 ones, however. You might want to look into the Open Source DB4O which works with .NET or Java. Go to: http://www.db4o.com[^]
-
I don't think the dataset was really designed to do that. .NET 2.0 datasets are greatly improved over the .NET 1.1 ones, however. You might want to look into the Open Source DB4O which works with .NET or Java. Go to: http://www.db4o.com[^]
I've looked at db4o and other OO/ORB's - but they involve substantial work. The DS is basically a relational architecture and Java is purely Object Oriented - inherently antagonistic paradigms (d**n - I said the P word!).- and predictably they don't mix well – like Chocolate Herring pie. The focus of my original question is to identify how others in my position have managed to get these things to work together in a nice, efficient manner. So far that leaves me with three things to consider … Replacing the DS completely means refactoring the code to use pure objects rather than the DS, adding custom binding code, adding all the object management logic (collections, relationships, database operations, matching the current behaviors exactly INCLUDING the errors, and tripling the project time with x thousand hours of regression tests, and possibly (probably) writing conversion test tools, enduser conversion tools, conversion backout tools, etc., etc., etc., etc., etc., etc., etc …… I wouldn’t want to do this for a simple standalone app let alone a multitier! it is far easier to just rewrite the whole thing. Alternatively, supplementing the DS with a layer of pure object classes means more objects to design, code and maintain, DS to Object/Object to DS translation logic with increased potential for data logic/transcription errors, more complex change management processes (which would really endear me to the CM team), and god knows how much time to rewrite the developer documentation, utility classes, etc. I don’t know that this isn’t as messy as the other option. The only reasonable option I've seen so far is to build specialized custom serializer/deserializer logic in both .NET and Java. While that brings its own issues with it, it is at least workable (subject to my continued research). Last point ... Eventually, we developers are going to have to force some integration standards on Microsoft, Sun, and IBM regarding the standardization between .NET and Java structures rather than trying to do it ourselves and being beaten bloody in the process. Nothing is impossible, we just don't know the way of it yet.
-
I am interested in hearing how the .NET Dataset / Java serialization/deserialization is handled in the increasing number of .NET UI/Java mid-tier architectures. I'm working on numerous applications for such an architecture and would prefer to retain the advantages of the DS at the client without impacting the "back-office" architecture. I'm very concerned regarding Datasets with multiple tables and relationships than a simple 1 table instance. I'd especially like to know packages used, custom work performed, gotcha's, performance, bandwidth, etc. if the many experts here don't have an answer, then it doesn't exist yet. Nothing is impossible, we just don't know the way of it yet.
If you have a database and you want to display relational data or do data processing via datasets, then datasets are a good choice. If your application is on the web, most of the time, you have to repopulate the datatsets to match the database each time you do a postback. With a Windows application, you don't have this problem but you run into the problem of keeping the data up-to-date. Datasets are great and have a lot of nice features but they do pose a resource hit when they grow beyond a certain size. As I said earlier, .NET 2.0 has improved performance and handles large datasets well. .NET 1.x datasets are slow. I use a combination of datasets, business objects and XML in my projects. Since I can store and query XML on MS SQL and Oracle, I have been using that option more and more in my projects due to their hierarchical nature. Neverthess, using the XML DOM to process large documents is not recommended, IMHO. Business objects do require more work! Nevertheless, you have more control of the process to tweak for performance and to reduce resource overhead. -- modified at 6:44 Wednesday 22nd February, 2006
-
If you have a database and you want to display relational data or do data processing via datasets, then datasets are a good choice. If your application is on the web, most of the time, you have to repopulate the datatsets to match the database each time you do a postback. With a Windows application, you don't have this problem but you run into the problem of keeping the data up-to-date. Datasets are great and have a lot of nice features but they do pose a resource hit when they grow beyond a certain size. As I said earlier, .NET 2.0 has improved performance and handles large datasets well. .NET 1.x datasets are slow. I use a combination of datasets, business objects and XML in my projects. Since I can store and query XML on MS SQL and Oracle, I have been using that option more and more in my projects due to their hierarchical nature. Neverthess, using the XML DOM to process large documents is not recommended, IMHO. Business objects do require more work! Nevertheless, you have more control of the process to tweak for performance and to reduce resource overhead. -- modified at 6:44 Wednesday 22nd February, 2006
Ok, everything considered, it is looking like I bite the bullet and use the XSD to flatten out the object classes. God Help me if we ever extend the DR classes to manage additional relationship information - I'll have to figure out a mechanism to DataRelations in the DS (might be an article or three there tho'). I did find an interesting bridging tool that I might consider here, information is a little sparse tho' but my guess is it's layered on JNI - JBind2.net. An alternate but similar tool is iKVM which is still a little immature. To use either would add more product requirement complexity to the CM environment. FYI: here is the MS take on the issue: Interoperability Fundamentals: Interoperability Technologies: Point to Point Integrating .NET in the Presentation Tier Both products mentioned carry hefty costs - Ja.NET (J-Integra), JNBridgePro. Example of using JNBridge: Calling Java Classes Directly from .NET. Nothing is impossible, we just don't know the way of it yet.