Leaderboard

Done.

It depends. If classes naturally belong together, and are not suitable for general usage - i.e. they are specialized for a purpose - I don't see a problem with "lumping them together". If they are merely building blocks, and will be reused in a multitude of other classes, it is better to try to keep them small and simple. The most challenging task is to avoid circular references and polluting "clean classes" with methods that use types from other classes. When you need such bridges - you need to take extra care in how you design them. Use dependency injection, use adapter/proxy classes, divide and conquer.

Small units if better than one large. It helps separate things and it helps to program in a more object oriented way.

I have just finished fixing all known bugs in the GExperts code formatter that were related to Generics. On top of that I fixed a few others. I am sure there are still more though, but because I rarely use Generics I haven’t seen them yet. So I need your help: If you have a lot of source code with Generics, please compile a new DLL and try the formatter on that code. Report any bugs on SourceForge.

I think Stefan suggests posting on Stack Overflow suitably tagged

Release notes: https://github.com/danieleteti/delphimvcframework#whats-new-in-delphimvcframework-322-nitrogen

We use the DelphiMVCFramework in a few systems. It's much nicer way to create a REST server than DataSnap or Rad Server. @Daniele Teti it's probably too late now but have you considered changing the name of the project? I stayed away from the project for longer than I should have because I saw the name and thought, "I don't need a framework to implement an MVC pattern for me". I had no idea it was a REST server until someone else actually cleared up the misconception for me. The current name is a bit like saying I have an internal combustion engine in my driveway rather than a car.