well. Your growth is in learning more frameworks and learn them better. You will have plenty to learn! And I don’t say this is necessarily bad. However…
time Test running time The bad The good Learning Standardisation Bad habits DB-Centric Quick project startup Extra work Upgrades Searching on Stackoverflow for answers Addiction Anything is good or bad in a particular context, for a particular set of goals.
the game of hangman. I wrote three versions of it; the first uses Spring and JPA. The second replaces JPA with plain JDBC calls. The third one removes Spring and uses the Servlet API.
50+ methods and are very low level and hard to use. One key thing to make #frameworkless work well is to write simple code. Therefore, it’s good to transform the servlet API objects into something simpler and easier to use. These are custom made for each project, similar but never exactly the same thing.
is still not enough; for any particular request, we probably want to transform the WebRequest into a specific request object that contains exactly what we need.
what Uncle Bob calls the “main partition”, that is, the place where objects are constructed. The main (of course) is executed once per process, while the servlet service method is executed once per request. It is a sort of “main” for the request.
the user trying to do, and dispatch to an appropriate service call. The code of the router is made much simpler by having some logic in the WebRequest and WebResponse.
IFs is simple and effective. If the service grows, it will probably evolve towards a table lookup. Again, this object should be developed afresh for every project/service. There’s no need to create a reusable “custom framework” here.
used by the business logic, but are relevant for audit/security/debug purposes. This information is saved in a way that does not pollute the business logic (compare the GuessRequest, shown later, with the Guess domain object) The QueryRunner is from Apache Dblib. It’s possible to write your own; it’s no more than 10 lines of code.
all the “guesses” of the player. This not exactly event sourcing, but it’s similar. I find that saving all the “events” involving an aggregate, with as little processing as possible at write time, makes persistence simpler, even when you don’t go full event- sourcing. Perhaps this way can be even better than full event-sourcing :-)
the same time simpler and higher level than the servlet API. The getOptionalParameter() and getMandatoryParameter() methods simplify the router and the service.
to run all tests 10s 5.5s 3.5s Time to run slowest test 7s 4-5s 1s # of tests 25 24 48 SLOC prod 360 424 643 SLOC test 358 357 745 jar size 30MB 17MB 6.3MB Judge for yourself.
time Test running time The bad The good Learning Standardisation Bad habits DB-Centric Quick project startup Extra work Upgrades Searching on Stackoverflow for answers Addiction