| A nice piece of work! But I'm curious about a few architectural decisions. What made you to decide to build each HTML page by hand? Code like this[1] makes my eyes bleed... reminds me of the faux-OOP HTML builder classes that used to be a fad among PHP programmers (or ISAPI & Delphi web developers of old) a while ago.. No offence, but much of your Manager.HttpHandlers.* codebase feels like messy, ugly PHP4 code ported to C#... What made you decide against template-based output rendering (Razor, NVelocity, NHaml, .liquid to name a few)? With template-generated output, the business logic layer could be decoupled from the UI. I had only a cursory glance at your code (and thus could be wrong), but it seems manager.io's DAL/BLL layer is intermingled within the GUI parts. The protobuf DLL was named protobufnet.dll in the MSI. But the proper filename should be protobuf-net.dll I think user input validation and error handling could be made more robust. Additionally, spawning 5 HTTP worker threads to serve a single user seems a little overkill. These are few of the issues I've noticed during the 5 minute tinkering with your assemblies. But don't let this critique discourage you. The app looks good - I guess end users won't care how it's built so long as it provides real value... PS: Thanks for the heads up about Eto forms! I'll give it a spin and see how it fares against Xamarin's XWT. [1] https://gist.github.com/anonymous/7003337 |