During the last semester I was taking a class on ASP.NET where we formed teams to write a website from scratch. The website was a “project manager” that would help users maintain projects, employees and customers. Given my experience with ASP.NET prior to the class, my team hit the ground in a full on sprint. We hit a wall when it came time to bind the site’s controls to the data behind it, in this case a Microsoft SQL database. The problems weren’t associated with a lack of knowledge but rather the gross disconnect between interfaces and the data with which they associate. It is easy to think that a textbox on a page can represent a name, but how that name is actually filled in can be the most complicated process.
This is just one instance of running into issues with data. How many times have you used a converter of some sort to scrub data or used a validator to make sure it can be stored? How many times have you written the same try-catch block for the SqlConnection class? How many times have you written a statement with “XmlDocument” or an instance somewhere in the middle? I have come to realize that there within the .NET Framework, there are many classes to get all the work done, but they aren’t really put together in a unified way. When you look at all the data-oriented classes (e.g. System.Xml.*, System.Data.*) you will find that there is no grand picture. For some reason the framework architects didn’t take a step back and see a possibility to unify the approach to reaching, converting, validating and consuming data.
So what is DMS? In short, the Data Management System prototype is a look into how possible it is to unify the approach to using data and whether or not it can make a developer’s life easier. The first step is to consider open architectures that are highly extensible and configurable. The current version of the DMS Prototype is focusing on just that by experimenting with converting runtime objects to and from XML. The important part isn’t the conversion; XML serialization has been done to death before. The important part to take away is that the serialization is being done in an abstracted manner. It is trying to gain as much information as possible from as little information as possible. The fewer attributes a developer has to use and the more generic they are, the easier life will be.
So what does a sample input object look like when using DMS? Something like the following class is perfectly suitable. Note that the only attribute being used here is the “NonSerialized” attribute. The others are sample attributes that may or may not be used at a later time.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | public class SampleObject { public int PublicInteger = 6; [NotNullable(-1)] [UniqueIdentifier] [NumberConstraint(0, double.MaxValue)] public int Id { get; set; } [LengthConstraint(0, 50)] public string Title { get; set; } [NonSerialized] public int Secret = 3; public List<int> RawData { get; set; } public int[] Data = new int[] { 5, 6, 7, 8 }; public SampleObject() { RawData = new List<int>(); RawData.Add(32); RawData.Add(64); } } |
I can hear you asking about how the output looks like. XML is a weird format because it can be very simple and incredibly useless (a la the built-in XML Serializer), very powerful and very messy, or somewhere in between. If you haven’t already guessed, I am shooting for somewhere in between. One of the reasons behind creating DMS is to replace the built-in serializer. For now I will save that discussion for another post, but know that it is an important issue that needs to be addressed. The following is the previous class run through the current version of DMS.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | <?xml version="1.0" encoding="utf-16"?> <ns1:SampleObject xmlns:ns2="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" xmlns:ns3="clr-namespace:System.Collections.Generic;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" xmlns:ns1="clr-namespace:DMS.Driver;Assembly=DMS.Driver"> <ns2:Int32 Name="Id">5</ns2:Int32> <ns2:String Name="Title">Hello!</ns2:String> <Generic Type="System.Collections.Generic.List`1[[System.Int32, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]" Name="RawData"> <ns2:Int32>32</ns2:Int32> <ns2:Int32>64</ns2:Int32> </Generic> <ns2:Int32 Name="PublicInteger">6</ns2:Int32> <Array Type="System.Int32[]" Name="Data"> <ns2:Int32>5</ns2:Int32> <ns2:Int32>6</ns2:Int32> <ns2:Int32>7</ns2:Int32> <ns2:Int32>8</ns2:Int32> </Array> </ns1:SampleObject> |
Overall, a little verbose but extremely powerful. So that is DMS in a nutshell. Would be happy to hear what you think of the idea and how the execution is going so far. You can comment here or use the Contact form.