Rearranged a bit for continuity ...
On Tue, 8 Oct 2019 19:44:55 +0200, Marc Kaufmann <marc.kaufman...@gmail.com> wrote: >Thanks for the response to a rather general question. I'll definitely have >a look at your code for Racket stories, which is live now if I see >correctly. Nice! > >I guess one concrete thing that I find surprisingly hard in my code is to >get rid of the number of times I repeat the structure of the data: > >1. write the SQL code to create the database >2. write the interface in Racket that deals with the database directly >(transform into Racket values, but it's still in the same groups) >3. write functions that need to know about this structure, because they >extract the information from part 2, but different fields for different uses >4. write the view that - quite often - looks like a subset of the database >and in my case calls functions from part 3, which again repeats huge parts >of what is in part 1 > >So if I have a user with 5 fields I am interested in, I find that if I >change part of my database schema, I usually update 3 (or more) places, >which tells me that I didn't get the abstractions right. (And I haven't >added tests, or else I'm sure I'd have another layer or 2 of repetition.) > : > >My guess is that I don't grok MVC, and therefore end up with all these >repetitions ... It remains to be seen whether you really understand what MVC is about ... but repetition unfortunately is a major issue with it, as it is with many other application design patterns. In general, embracing MVC as a design philosophy won't reduce your work at all - in fact it likely will increase it. MVC does nothing whatsoever to reduce the application's unique processing - it only addresses ways to structure the application. But usually it will produce a program that is more modular and clearer to understand. [But your observations about maintenance are quite valid.] One of the issues I have with MVC is the way it typically is presented: data flow in the tutorials tends to be exaggerated and overly complicated, and the explanation typically revolves around DBMS and graphical UIs that simply aren't relevant to it. As a design pattern, MVC dates from the 1960s, from the era of CRT display/edit form-based applications. The View and Controller historically were integrated, and the "Model" was a memory cache of one or more data records. [Relational DBMS didn't exist in the 60's, but there were many varieties of file based record systems. Dedicated DBMS software based on network/graph and hierarchical models appeared in the 70's, and then relational models appeared in the 80's.] Obviously MVC can be - and has been - generalized to separate the various concerns, divorce the "Model" from its "data record" origins, and to allow more complex communication/control patterns. But the modern notion of MVC has become so interwoven with DBMS, graphical UIs, event handling, reactive programming and web services that people learning about it often have a hard time figuring out what it really means and how to use it effectively for their own programs. MVC is simple when you understand what it was designed for originally. Then there is the proliferation of simplistic MVC object "frameworks". These typically address DBMS backing storage for the Model and little or nothing else. Trying to use them for rapid application development too often results in your application doing all the work, and your high powered DBMS server being turned into little more than a very expensive file server. <frown> > : >The continuation passing style actually suits my use cases much better >than storing state in the database -- except that I need to be able >later on to recreate the path a user took, in order to figure out what >happened, so I have to store it in an easy-to-interpret way in the >database. > ... part of the reason I don't grok it may be that most >beginner resources have websites that are less stateful than what I >do, which is much more like a game with many action nodes and >randomization. I should probably have a look at Realm of Racket and >see if I can't port the big-bang ideas to the web server. MVC per se has no problem with large amounts of state - the scope of the Model, and how and where it is maintained, largely is irrelevant. There doesn't need to be one big unified data store - there can be many little ones. I think part of your problem it is that you are integrating/conflating what are purely implementation issues - such as whether to pass state via continuations vs storing it in DBMS - with higher level design issues like whether to use MVC vs some other equivalent architecture. On the subject of database development, your best bet for reducing effort is to invest in a database modeling tool. There are many free and/or reasonably priced (for single developer) tools that will generate DDL and simple select/update DML or view code for you. The better ones also can generate morphing DDL for structural alterations (though IMO that's better done manually), and they offer other niceties like graphical views of your tables and their relationships / linkages, easy manipulation of references (e.g., draw an arrow from one table to another to create an FKEY reference), structural consistency checking, data display/edit, and other goodies. High end [read "much more expensive"] UML/ERD tools can generate application frame code from database structures and process flowcharts. However, offhand I'm not aware of any that generate Scheme or Lisp code - it almost always is Java or C++ (or more recently C# or node.js Javascript). Most likely, there's something you'll like that will fit your budget. Hope this helps, George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/u5jqpedeh2vhpf6tsfmn2333msr1hoicpv%404ax.com.
