I cannot understand what you are trying to say or prove with the rest of your comment. May I suggest that you start your own blog, or keep to the topic.

Perceived limitations are not the same thing as real limitations. Using a tool in a way unintended by its design leads to perceived limitations. In software, bitching about it is better than not bitching about it. Our bitching is a tool to educate future design. Using a tool has consequences, and we’re far better off reflecting on those consequences than falling into habits encouraged by the tools we use.

Buck Showalter, a World Series winning manager, once asked a third base coach he was interviewing how well he did his job the previous season. The third base coach said, ‘I had a great year. Nobody I waived home got thrown out.’ Showalter told him, ‘No, you had a bad year. If you didn’t get at least one person thrown out, then you were afraid to win. As a manager, I want a third base coach who will steal runs for me.’ (paraphrased)

Come to that, the biggest lesson I learned from your blog entry was that CG developers don’t care to document what those real limitations are, so that we may compare them with your real limitations.

So, what’s the big picture of SCID? Since most application developers cannot tell the difference between a database and an appliance that only requires plugging in, I’ll start there.

In your typical non-subvertible DBMS, security is organized into a realms model. Typically, there are two major realms: server and database. A server realm is a container for one or more database realms. Although CRUD is performed in a database context, users must have separate privileges to access the server and database. Note that this is specifically privilege separation, not privilege escalation: Just because you have access to the server through valid credentials does not give you access to any databases. The database must recognize your credentials e.g. grant you access to itself.

The remarkable aspect of relational databases is that they are complex systems that can describe themselves to the user, insofar as the user has privileges to the database-wide schema and cells that store the explicit state of the ‘instantaneous database’ the schema matches. If checking out (reading) the schema is ‘public’, then everything about the schema is accessible from the server realm. Traditionally, checking in (rewriting) the schema is ‘private’ and limited to the ‘dbo’ (database owner) or some surrogate user equivalent to the dbo, because the public should not be in control of the schema.

Users of IDEs unknowingly interact with this realms model on a regular basis. Instead of the ’server’ and ‘database’ concepts, they have ‘repository’, ’solution’, and ‘project’. In the SCID model, all three of these are maintained by the IDE but manipulated by the user. A Continuous Integration server was a foreseeable concept in the context of SCID. Continuous Integration checks for code hygiene and data hygiene, just as a normalized database with sufficient integrity constraints ensures ‘The Enterprise Data Model’ is not ’smashed’. Steve McConnell’s ‘Daily Build and Smoke Test’ strategy describes an early desire to bring the principle of non-subversion from the domain of discourse world into the application model world, and Continuous Integration moves to perfect it (but falls short). In any discipline, there is a correlation between having realms and preserving the sanctity of each realm (hygiene).

What most people don’t realize about Continuous Integration is that not only does it help prevent ‘diverging or fragmented development efforts’, it also yields applications with growing functionality that consume more and more of the schema. With Service-Oriented Architectures, this consumption of the schema is now unbounded, because we’re not only consuming our Enterprise Data Model with Enterprise Resource Planning software, we’re consuming other organization’s Enterprise Data Model as well with Customer Relationship Management and Supply Chain Management software.

The modern IDE’s compiler pipeline is an ever enhancing form of Continuous Integration, presenting live feedback and clearer diagnostics. It uses the Read-Eval-Print-Loop model in the most exotic way imaginable: through the traditional relational database method of computational reflection.

But what are the schemas for an IDE? The programming language is the default assumption, but today it is an abstract tree of artifacts. It is not merely an Abstract Syntax Tree, it is an Abstract Artifact Tree.

Being able to execute these abstract artifacts is one of the holy goals of modern software engineering e.g. executable UML. But don’t just agree; ask yourself, why?

Probably the most important design pattern in Informatics is the instruction set architecture. Traditionally, it is the key interface that allows many hardware *implementations* to run identical software. Modern systems virtualize this concept: the CLR translates CIL (Common Intermediate Language) into a specific processor’s instruction set architecture. The CLR and similar execution engines are bringing the end to failed attempts at component-oriented programming like CORBA, and therefore technologies like COM and SOM. COM/SOM were both intended to allow the embedding of ‘active objects’ within an application. Replacing it with CIL Assemblies and Components returns us to taking advantage of the key interface provided by an instruction set architecture.

The major difference is we’re giving birth to Reflective Application Models that use concepts like TheGlobalModel object, which provides a facade to execute user actions in an interpreted and secure-by-design manner. Doing so will wreak chaos on how we model encapsulation. Morever, we are consolidating command languages into pictorials and visual languages, because users naturally assume consistency and reason by analogy. What do you think a Dashboard is?

Even so, I belive that MVC (or MVP, or whatever, see below), is a factor in creating reusable components when building applications. With loose coupling and separation of concerns you end up with a model that doesn’t depend on the controller or the view, and thus it is reusable for other applications that do something similar (you can find one use case in one of my comments above where I have build an application that is basically a subset of a larger application).

Depending on how you design the rest of the application even parts of the view will be reusable. For example a login form will be reusable in any other application that has the need for a login form, but it will only be reusable if it doesn’t contain application specific logic, and by applying the ideas of MVC it won’t have.

So yes, you are probably right in that reusability isn’t a core concern in MVC, but it is a consequence. Unless you do other things that limit the potential reusability, like tightly couple your views to a global variable.

—

Re: The proliferation of ideas about what constitutes MVC creates ensuing confusion about what MVC actually is.

Well, that depends on what you mean that MVC actually is. If you mean that it’s something specific, then you are part of the confusion-creation. “MVC” has had a few very specific meanings in different environments, see for example Martin Fowlers essay on GUI Architectures ( http://martinfowler.com/eaaDev/uiArchs.html ), but I would say that nowadays its meaning is vague because, as Fowler points out, many things have changed since the first few incarnations of the idea, and many of the problems that motivated its creation are no longer problems.

I try to avoid using the term MVC because I don’t think it’s helpful (I didn’t mention it in the original post at all), it’s almost always used as if it was something very specific, but in reality it’s very vague.

—

I glanced through the global model part of the thesis, and it sounds like DrJava uses more or less the same bastardized service locator idea that Cairngorm does. I don’t understand the connection to the Liar View though.

Speaking of Liar View, I think there is one very good solution to the problem: Presentation Model ( http://martinfowler.com/eaaDev/PresentationModel.html ), it’s a nice way of making the view more testable, and avoid the problem of the Liar View. Paul Williams has written more specifically how to use Presentation Model in Flex: http://weblogs.macromedia.com/paulw/archives/2007/10/presentation_pa_3.html and how to use it to simplify testing of views: http://weblogs.macromedia.com/paulw/archives/2008/04/unit_testing_us_1.html .

TheGlobalModel object is also covered in Eric Allen’s explanation of The Liar View bug pattern. Allen does a much better job describing the details.

The point behind MVC is NOT to achieve reusability, though. This is the unfortunate viewpoint that all these incurable do-it-yourself framework creators have. The point is to separate concerns. Reusability emanates from the Producer / Consumer Model, because it defines how you view the application’s relationship with the service; thus, you can reuse the entire application ‘above’ the data layer.

Come to that, nothing about MVC is reusable by default. In order to reuse something, you have to encapsulate, either with a pure function or an object (which is stateful by default, and therefore adds destructive assignment (explicit state) into your application model). To encapsulate, you need a variable, which implies two further concepts: an identifier and a store.

The proliferation of ideas about what constitutes MVC creates ensuing confusion about what MVC actually is. At its kernel, MVC is an incomplete application model. It does not describe how to represent application state, it only defines where to put application state (in the Model). It does not define a model for encapsulation. If you read Stoler’s thesis, you’ll note that their use of reflection in DrJava forced an unusual model of encapsulation. Due to their use of stateful concurrency, they needed an encapsulation model designed to avoid livelock as well as to avoid security issues.

The lesson to take away here is that design is about constraints. A framework imposes constraints. This is a trade-off first an foremost at the canvas level: instead of using a blank canvas for your blueprint, you are forced to take into account design parameters provided by business constraints and technology constraints.

However, these constraints should be independent and therefore you should be able to address each constraint with a model in a kernel language. Doing so allows you to compose, not necessarily reuse. Constraints create context, which implies some degree of specialization. Specialized components are by definition less reusable than general components. What you really want to do is compose together unique constraints. If your design does not allow you to compose together specialized components, then you have an “unholy mess”: coupling between specialized components with independent concerns. This describes the ‘low cohesion’ idea, because there is no way to do ad-hoc association (’high cohesion’).

Anyway, enough ranting.