-
-
You need to build some experience to get really effective working with XML. I've struggeled with quirks and rarities the past days. Today Wayne Allen solved my final non-trivial problem with SelectSingleNode, XmlNamespaceManger and XPath. Who would beleive that default namespaces wasn't supported? It should at least be documented!
In a couple of hours my solution for continous converting and adding of XML documents to an Microsoft Excel 2002 formatted XML file as new rows is finished.
Basically it uses one XSLT the first time to create the file, worksheets and headers for the XML data. Then another XSLT is used sequentially to add more rows to this excel xml file as my service receives messages. Great and (almost) simple solution for reporting and stats. The only flaw is that I didn't see any way to do this with pure XSLT, so the parsing into the main document has to be done by a C# method (where the XPath problem occured).
-
-
Any minute now I'll maybe get the time to really have a thurough look at Microsofts Windows forms sample app TaskVision. I would have had a pretty good idea about how it is built now though if they (Microsoft) would start using UML to document their samples. The guys at EMEA that are working on the new Patterns & Practices initiative are using UML for all their work, which is GREAT. Probably it has something to do with most of them beeing former j2ee wiz's.
If I get the time I'd like to sit down and make the diagrams. I'd like everything in the 4+1 view: Use Cases, Logical View, Deployment View, Component View and so forth. I'd like package diagrams for the namespaces and class diagrams for the important classes.
Instead of UML i see clouds, boxes, computers, and funny looking humans all connected with all kinds of arrows, lines and graphics. This should be considered the same way as a house documented with crayons on a napkin. The house might be fantastic, but it's hard to tell for sure.
I did notice btw that TaskVision has a good example of the concurrency functionality in ado.net that maybe Frans would be interested in with his concurrency dilemmas.
-
-
It's not only Al Quaida (or whatever spelling that is) that have something against Norwegians these days.
The System.Xml.Xsl.XslTransform also dislikes norwegian stuff. Putting an Æ Ø or Å into a comment section of an xslt stylesheet causes the function to crash with the error message:
An unhandled exception of type 'System.ArgumentException' occurred in system.xml.dll
Additional information: Invalid byte was found at byte index XX.
This especially sucks when my name includes an Ø and I'd like to tag my name to my work. Another two hours wasted in the hard learning of xsl transformations. *Grumpy*
-
-
Took quite some time to find out, but it seems as though the System.Xml.Xsl.XslTransform.Transform method does not write the Xml Declaration when you pass it a System.Xml.XmlDocument. Given the following Xml input (simple.xml):
<
root>SomeData<root>
And this xsl stylesheet (simple.xslt):
<
xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" />
According to this article the result should include the Xml Declaration by default.
I tested using this code:
System.Xml.Xsl.XslTransform xslt = new System.Xml.Xsl.XslTransform();
xslt.Load("c:\\simple.xslt");
XmlDocument xml = new XmlDocument();
xml.Load("c:\\simple.xml");
System.IO.Stream stream = new System.IO.MemoryStream();
XmlWriter xw = new System.Xml.XmlTextWriter(stream, System.Text.Encoding.UTF8);
xslt.Transform(xml, null, xw);
The XmlWriter contains only "SomeData" when this code has executed. If I use a XPathDocument instead of the XmlDocument though:
System.Xml.Xsl.XslTransform xslt = new System.Xml.Xsl.XslTransform();
xslt.Load("c:\\simple.xslt");
System.Xml.XPath.XPathDocument xml = new System.Xml.XPath.XPathDocument("c:\\simple.xml");
System.IO.Stream stream = new System.IO.MemoryStream();
xslt.Transform(xml, null, stream);
Then the output is as following:
<xml version="1.0" encoding="utf-8"?>SomeData
Anybody know why?
-
-
I have been using Ingo Rammer's RemotingHelper class for a while now. I'm not a big fan of a lot of statics in my apps so I rewrote it to a Singleton class based on microsofts suggestion for C#. The problem with this was that the constructor for the RemotingHelper class were run before RemotingConfiguration.Configure()which naturally caused problems.
As a consequence I rewrote the Singleton to do lazy initialization like this:
public
sealed class ServiceLocator
{
private static ServiceLocator instance;
public static ServiceLocator Instance
{
get
{
if(instance == null)
instance = new ServiceLocator();
return instance;
}
}
private ServiceLocator() {}
}
Are there any reason that this will cause any problems? This could maybe be an alternative strategy in the C# pattern?
-
-
Andres stepped up quickly with some hints to my previous blogentry. I tried out the ADO.NET Powertoys which contained several features. Because it was poorly documented, and I just needed one of the features, I think I'll wait for a later release.
I could have given DeKlarit a shot, but I simply like fiddeling with architecture too much to give away everything to a framework:)
The solution was updating the generated code for the typed datasets with serialization for the DataTable objects. Two additional lines of code is needed per DataTable, the one above and the one below the class def:
[Serializable()]
public class MyDataTable : DataTable, System.Collections.IEnumerable
{
iternal MyDataTable(SerializationInfo info, StreamingContext context) : base(info, context) {this.InitVars();}
}
In other words the inherited DataTable object needs the serialization attribute and to expose a constructor for serialization that passes the parameters directly to the baseclass. Doing this for every class every time it's regenerated really is no optimal solution, bot it does work over .NET Remoting.
-
-
I didn't really like the DataSets too much. I felt they did too much. After having a discussion on strongly typed datasets with Roy Osherove a couple of weeks ago I decided to put my DataAccess framework with ValueObjects, DataAccessObjects and ServiceFactory/Locators on the shelf for a little while and give strongly typed datasets a real go.
I have to admit that this feels pretty good. I'm starting to get the same experience as Jeff did back in february (only I'm slow:)
I like the notion of creating the XSD as the "first-point-of-action". XSD is not dependant on the datasource and could possibly be generated to any kind of transport, dataset as well as custom business entities (and collections of these).
So what maybe would be a good idea is if XSD's could be reversed into database schema (and sp's) just as you can create XSD from SQL Server objects via the Server Explorer in VS.NET.
The remaining question for me now is how to handle typed datasets with .NET Remoting. There seem to be some options:
1. Share the xsd between Server and client. Generate the typed data set classes separately. Let the server write the typed dataset to string (WriteXml) before shipping it off to the client. The client uses ReadXml on the typed dataset. This way the only dependency between the server and client is the xsd.
2. Something new in some new version? I read this post where it is stated that typed datasets will be supported over remoting. But how?
3. Use a tool like XGoF to generate an Interface based on the server typed dataset and distribute this interface to the client. There might be issues related to custom DataTable classes generated within the typed dataset class not beeing marked as [Serializable]. Also you'll probably have to add the MarshalByRefObject attribute manually.
I didn't get to try out this last option because I didn't bother fiddeling with the opensource project so it would build. But the idea seems pretty good if you are distributing remoting interfaces to the client anyways.
I saw that Ingo Rammer discusses this topic in his training session, but I sure can't afford flying in Ingo to figure this one out:)
-
-
Roy found the xsd tool recently and got the typed datasets to scale. I still don't like them.
What is really the difference in beeing dependant on the xsd schema than a dll reference? If you do the Service Oriented approach on this problem you'll come down to what Clemens and Steve predicates these days: it's all about contracts.
The xsd schema for the typed datasets is basically just a .net platform specific contract for one given message type between the Data service layer on top of the database and the service that requests this data. Doesn't it feel a bit like WSDL? You get some xml schema type thing, use a .net framework tool and generate a class. It's the same thing.
This leads down to the question causing the most confusion in my world these days;
What place does object orientation have in a Service Oriented, message-driven, distributed architecture?
Objects can by definition not pass far connections. Messages can. So if you are building applications for a distributed environment, the OO stays in one location. Then messages are sent between these systems. This applies even to the data layer, although in a lesser degree.
In this case, if the datalayer is so tightly bound to the service that you don't need a message contract, but can use a TDS, I can't really see why this application couldn't have used regular business entities in a shared assembly.