0

I appreciate if someone could clarify my confusions about the following quote from Distributed Systems, by Coulouris et al:

Consider the functional decomposition of a given application, as follows:

the presentation logic, which is concerned with handling user interaction and updating the view of the application as presented to the user;

the application logic, which is concerned with the detailed application-specific processing associated with the application (also referred to as the business logic);

the data logic, which is concerned with the persistent storage of the application, typically in a database management system.

Consider the implementation of such an application using client-server technology and two-tier and three-tier solutions in Figure 2.8 (a) and (b).

In the two-tier solution, the three aspects mentioned above must be partitioned into two processes, the client and the server. This is most commonly done by splitting the application logic, with some residing in the client and the remainder in the server (although other solutions are also possible).

In the three-tier solution, there is a one-to-one mapping from logical elements to physical servers and hence, for example, the application logic is held in one place. Each tier also has a well-defined role; for example, the third tier is simply a database offering a (potentially standardized) relational service interface. The first tier can also be a simple user interface allowing intrinsic support for thin clients.

enter image description here

Do the figures specify the presentation/application/data logics? If so, how?

  • Do the figures specify the presentation logic exactly as "user view" and "control" (in both two tier and three tier cases)?

  • Do the figures specify the application logic exactly as "data manipulation" and "Application" (in the two tier case)?

  • Do the figures specify the data logic exactly as "data management" (in the two-tier case) and "database manager" (in the three-tier case)?

Do the figures specify the components of the MVC framework? If yes, how?

  • Do the figures specify "V" in MVC exactly as "user view" (in both two tier and three tier cases)?

  • Do the figures specify "C" in MVC exactly as "control" (in both two tier and three tier cases)?

  • Do the figures specify "M" in MVC exactly as "data manipulation" and "Application" (in the two tier case), and "data management" (in the two-tier case) and "database manager" (in the three-tier case)?

How do the presentation/application/data logics and MVC correspond to each other?

  • Does the presentation logic exactly consist of "V" and "C" in MVC?

  • Does "M" in MVC exactly consist of the application logic and the data logic?

1

MVC (model-view-controller) is an architectural pattern, but it does not map directly into N-tier architecture: Those are more or less orthogonal, and in principle each layer can have their own (even multiple) MVCs. And of course N-tier architecture can use MVC somewhere or not.

For some simplified system, maybe one can somehow put model at some business domain layer, between application and persistence layers. But View and Controller will necessarily be in representation and application layers both. But I think this is a misleading: MVC and 2- or 3-tier are not exactly comparable, and actually Layers is an architectural pattern on it's own.

Application layer and business domain layer usually (but not necessarily) are at application tier, as well as persistence layer, which connects to the "Data(base) management" "tier".

As for multiple MVCs, one can imaging having it's very own MVC in the representation layer (for example, in-webbrowser frontend can be built with MVC pattern), in application layer (view, controller) + business domain (model). With some technologies it's even possible to span MVC across those three layers. Persistence layer can have it's own MVCs. And if we go into data management - it can also have it's very own MVCs.

That is, even with multi-tier architecture we can have logical layers and MVCs inside or across.

  • Thanks. (1) "in principle each layer can have their own (even multiple)", do you mean "tier" by "layer"? (2) Could you elaborate how "each layer can have their own (even multiple)"? (3) Are "business domain layer, intermediating application and persistence layers" and "representation and application layers" synonyms for presentation, application (i.e. business) and data logics in the book mentioned in my post? – Tim Jun 5 at 17:53
  • (4) " View and Controller will necessarily be in representation and application layers both", do you mean "view" must be in both "representation and application layers", and "controller" must also be in both "representation and application layers" – Tim Jun 5 at 18:24
  • My answer in short: MVC relation to "tiers" or "layers" is in general arbitrary. It's basically a loop, which can be found inside or across tiers and layers. Here by tiers I understand software units, which can reside on different physical machines. And by layers - abstraction layers of the whole stack. – Roman Susi Jun 5 at 18:48
1

Do the figures specify the presentation/application/data logics? If so, how?

They don't specify them in any precise sense, but they do show a high level logical organization of the system. Presentation logic would be a part of the user-facing tiers (desktop GUIs, web pages, mobile device screens). Most of the application logic would be in what's on both pictures marked as "Tier 2".

"Tier" is a somewhat overloaded word, and people mean slightly different things by it, but these tiers may be just the logical organization of the source code, or how the code is packaged into libraries (e.g., DLLs), or they could represent different physical machines. My impression is that "tier" most often means "physical tier".

In real systems, things may not be organized so neatly. E.g., some of the application logic may need to be moved, or even duplicated on the user-facing tiers, to provide better user experience. Sometimes, parts of it may end up in the database tier, for various practical reasons (both good ones and bad ones).

Do the figures specify the presentation logic exactly as "user view" and "control" (in both two tier and three tier cases)?

Again, nothing is specified precisely here, but yes - presentation is concerned with displaying information and user interface, and this is what we call "Views". "Controls" here most likely refers to just the things that the user can do with the application, or it may even literally refer to GUI controls (buttons, textboxes, checkboxes, menus, things like that).

Do the figures specify the application logic exactly as "data manipulation" and "Application" (in the two tier case)?

Roughly, yes. One way to think about this as application logic being separated by concerns of the two tiers (e.g. the fine-grained logic that can be done on, say, a phone, vs the more coarse-grained, resource-intensive logic that executes on some backend service).

I'll repeat the image here for easy reference:

enter image description here

The idea with having separate notions of presentation and application logic is that your application logic (the thing that your application actually does) shouldn't depend on the way stuff is being shown to the user (the presentation logic), and on the intricacies of how exactly it's done. The image here is not really designed to show that; it's more focused on the high level organizational view of the system.

Do the figures specify the data logic exactly as "data management" (in the two-tier case) and "database manager" (in the three-tier case)?

Yes; it just means that there's some kind of a database that stores the data and provides various capabilities that let you query it, etc. But, depending on the application, it could be something as simple as a file, and some code that governs how you read and write to it.

Do the figures specify the components of the MVC framework? If yes, how?

No. There's no notion of MVC in these pictures.

Do the figures specify "V" in MVC exactly as "user view" (in both two tier and three tier cases)?

If MVC was shown here, the V would roughly correspond to "Views and Controls"

Do the figures specify "C" in MVC exactly as "control" (in both two tier and three tier cases)?

No. Here "controls" most likely just refers to either the on-screen widgets (buttons and such), or just the things that the user can do (in the same sense you'd use the word "controls" in a video game). In MVC, C stands for "Controller", which is a component that sort of coordinates the interaction between the Views and the Model (see below).

Do the figures specify "M" in MVC exactly as "data manipulation" and "Application" (in the two tier case), and "data management" (in the two-tier case) and "database manager" (in the three-tier case)?

Not quite. The M in MVC is not about data storage. MVC is a GUI pattern, so it's concerned with the GUI and the presentation logic. In MVC, you can think of the Model as of a black box of sorts that encompass "the rest of the application"; from the presentation-related point of view, we don't really care (and we want to be isolated) from the internals of the rest of the application - we just want to know how to interact with it. A more useful way to think about it, though, is that the Model corresponds, on a very conceptual level, to the application logic, or to a part of the application logic that's relevant for this particular view; in contrast, the layered/tiered view is a high-level overview of the application as a whole.

That said, there's a lot of history and a lot of terminology here, and there are different variants of MVC itself, and related patterns like MVP, MVVM, etc. You'll encounter terms like "ViewModel" and "Presentation Model" - this is not the same as (or related to) Model (if anything, they are associated with the Controller, or Presenter in MVP). Then there's Web MVC where Views correspond to web pages (as in, HTML/CSS/JS source), or templates that generate such pages, rather then desktop widgets. There too you may encounter "view models", but these are often just data bags that serve as a way to pass data to the view, so again, it's a different notion.

Also, the original MVC (when first invented/described) was different than how we think of it today - back then, every little widget had it's own trio of MVC components (as in, every button would have its own View that could draw it, a Controller that knew how to deal with user input, and a little piece of application logic that was represented by its Model). That's not how we use the pattern today; typically, a View would be an entire screen, or maybe a panel within that screen.

How do the presentation/application/data logics and MVC correspond to each other?

Since MVC is a GUI pattern (some might call it GUI architecture, but it doesn't really matter), most of it is about the presentation layer, and the organization within it.

Does the presentation logic exactly consist of "V" and "C" in MVC?

I'd say that's roughly correct; at least, V & C are concerned with the presentation logic (but as C also interacts with the Model, one might say that it handles additional concerns as well).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.