• entries
    437
  • comments
    1000
  • views
    335100

First version of FlatBuffers in .NET

Sign in to follow this  
evolutional

1397 views

I've committed by first alpha version of the FlatBuffers port to .NET to GitHub.

Since my last post, I decided to port the Java version to .NET as straight as I could, which means the use between Java and C# should be similar.

I ported the JavaTest buffer creation code; which looks as follows: var fbb = new FlatBufferBuilder(1); // We set up the same values as monsterdata.json: var str = fbb.CreateString("MyMonster"); Monster.StartInventoryVector(fbb, 5); for (int i = 4; i >= 0; i--) { fbb.AddByte((byte)i); } var inv = fbb.EndVector(); Monster.StartMonster(fbb); Monster.AddHp(fbb, (short)20); var mon2 = Monster.EndMonster(fbb); Monster.StartTest4Vector(fbb, 2); MyTest.Test.CreateTest(fbb, (short)10, (byte)20); MyTest.Test.CreateTest(fbb, (short)30, (byte)40); var test4 = fbb.EndVector(); Monster.StartMonster(fbb); Monster.AddPos(fbb, Vec3.CreateVec3(fbb, 1.0f, 2.0f, 3.0f, 3.0, (byte)4, (short)5, (byte)6)); Monster.AddHp(fbb, (short)80); Monster.AddName(fbb, str); Monster.AddInventory(fbb, inv); Monster.AddTestType(fbb, (byte)1); Monster.AddTest(fbb, mon2); Monster.AddTest4(fbb, test4); var mon = Monster.EndMonster(fbb); fbb.Finish(mon);
My test code will read a file output from C++ and assert against it being valid (readable). Then create the same buffer in .NET and run the same tests against it; exactly like the JavaTest does. My .NET version passes both sides, so it means we should be compliant to the FlatBuffer format and can achieve interop between C++ and Java.

By being in C#, this should be usable from Unity - either as code, or binary. I haven't verified this yet though.

Now that I've got a working version, I can start to address my other concerns - that it doesn't "look" nice to .NET developers ;)

What this really means is that I'll be building a reflection based serialization layer on top of this, so we can do code-first and/or transparent POCO serialization from the FlatBuffer format.

EDIT:

After thinking about this, there's a few things I want to look at improving. The first version was a straight port, and this works fine but sticks out in C# like a sore thumb.

  • Modify the C# code generator to create a property for get access (eg: not monster.Hp(); but monster.Hp; )
  • Change the generated C# objects to XXXReader and XXXWriter; this lets me have cleaner split of read/write concerns
  • Refactor the FlatBufferBuilder into a FlatBufferReader and a FlatBufferWriter - again, to separate the concerns a bit
  • Look into a nicer way of handling arrays/vectors
  • Build a "typemap", effectively a definition of a FlatBuffer type which can be used to serialize or code gen POCOs
  • Add the Serialization support for POCOs (mentioned above)
  • Add a MediaTypeFormatter for ASP.NET / etc to allow simple model binding with FlatBuffer format
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now