• entries
437
1000
• views
334967

# First version of FlatBuffers in .NET

Followers 0

1372 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

3
Followers 0

There are no comments to display.

## Create an account

Register a new account