MVC is conceptually elegant:
user input is handled by the controller
the controller updates the model
the model updates the view/user interface
+----| V |<----+
user | +---+ | updates
input | |
| C |--------->| M |
+---+ updates +---+
However: The ...
Do I really have to make 24 use cases?
Only if everything you write is CRUD.
Refer to the diagram below:
Your assertion is that you will have six different entities, and 4 methods (Create, Read, Update and Delete) for each entity. But that is only true in the yellow circle in the middle of the diagram (the Entities layer). It is pointless to create 24 ...
If I understand correctly, this means not to use a design pattern until it makes sense to do so, correct?
Don't start off saying you're going to use the Strategy Pattern, wait until you write some code, and if using the Strategy Pattern makes sense for your design, then use it.
Yes. Technically, you may realize that the strategy pattern is ...
Android applications are fundamentally built around Model-View-Controller (MVC) - MVP sounds like the same thing, although I've not heard the term before. Activities fill the role of Controller, XML Views are just that (although you can build them programmatically in the Activity - it's just easier and simpler to do it in XML), and the Model you write ...
What Bob Martin called "Clean Architecture" is more a "meta architecture", a high level guideline for creating layered architectures. It does not say anything like
"There must be a Model layer, a View layer and a Presentation layer, and they must be implemented using MVP",
it contains only more general rules for the layers like "dependencies must go ...
Logging is a cross-cutting concern. There is no right place for logging; you do it where you need to.
MVC is agnostic in that regard; it has nothing to say about where you put lines of code that call your logger.
I've seen it done two ways.
The first way is to do everything using CRUD methods. That's essentially the way you are describing: Create, Read, Update and Delete. Most Object-Relational Mappers (ORM's) support these four operations.
The second way to do it is to provide a Service Layer. The Service Layer exposes methods that embody business operations. ...
Yes, it is fine.
Applying MVP design pattern means having MVP triplets (model-presenter-view) per every (even a bit complex) item to display. The logic goes to the model, and the presenter is there just to glue things.
According to Martin Fowler's description of MVP ( http://martinfowler.com/eaaDev/uiArchs.html )
Of the View portion of MVC, Fowler says:
The first element of Potel is to treat the view as a structure of widgets, widgets that correspond to the controls of the Forms and Controls model and remove any view/controller separation. The view of MVP is a ...
I would put logic like this in the Presenter. One of the important jobs of the Presenter is to put the data into the correct form for your View. This will make it easier for you to swap out views in the future.
In general, you should try to avoid putting a lot, if any, logic in your View. The only thing in your view should be visual display code and basic ...
From the first page in the Shoes manual:
Shoes is a tiny graphics toolkit. It's simple and straightforward. Shoes was born to be easy! Really, it was made for absolute beginners. There's really nothing to it.
From this statement I would say that Shoes was not really designed with large-scale apps in mind.
You may be able to implement an MVP or MVC pattern ...
"Is the coordinator and translator between the Model and the View."
indicates that your Bridge is the Presenter in an MVP architecture.
MVP and MVC are very similar, except that in MVP only the Presenter observes the Model while in MVC the View is also allowed to directly observe the Model (without the Presenter as a "Bridge").
In the MVP pattern is the View is "dumb". It doesn't really do anything. The presenter acts as the controlling object in the heirarchy, while the Model stores the data and has business logic methods on it.
That doesn't preclude the View from firing events, which are hooked by the Presenter to methods or properties on the model, or to other testable logic ...
I don't have any experience on Android programming, but having a short look into some introductory Android programming tutorials I don't see a reason why MVP should be less useful as in any other event driven framework. The Activity class is not very different from the Dialogor Form in other frameworks, so it should be easy to create an "Activitity Presenter"...
I think thorsten müller worded the answer in a way that might confuse people (although his answer is good).
The view never directly acts on the model layer.
the view should really have no knowledge about models.
Both of these statements are true, but allow me to clarify.
When thorsten says that a "view never directly acts on the model", ...
Displaying a second view on btnShowView2.Clicked is some kind of business logic, so the right place for implementing this is in the event handler of presenter1 which deals with that event (I assume that presenter1 is registered to all relevant button-click events of View1). Lets call it HandleBtnView2Click, so the initial code inside that handler might look ...
When the HTTP request is completed, it will return some data, and the model gets updated by the responsible part of your system. Then raise an event which tells everyone who subscribed to it "new data has arrived", but do not pass the actual data in this event, only the relevant information for the subscribers which part of the model has changed. The event ...
There are several variants of the MVP around since its original design in 1996 by Mike Potel. Martin Fowler discusses some of them in another article on GUI architecture.
One of the key differences between the variants is whether the view is totally isolated from the model or not:
In the first case, the presenter is the man in the middle of a "passive ...
In MVP, the Presenter replaces MVC's Controller. The difference between the two is that the Presenter directly manipulates the View. It is designed for UI frameworks that are primarily event driven (like Windows Forms) without heavy support for rich data binding that would lend to the MVVM pattern (like WPF). Otherwise a lot of the logic for managing view ...
MVP is definitely useful for Android. It helps to organise and unit test your code. And the best part is new people reading your code will be able to understand the code and will start contributing soon as they know what should go where. Here is a very helpful link to understand MVP with examples.
Here is a brief explanation of all the three components of ...
I suspect one of the things that's confusing you is that there are two entirely different patterns that are both commonly called model-view-controller.
There's the original, as implemented in smalltalk and which is useful for local gui systems, and theres what I tend to think of as web-mvc, which swaps around some of the responsibilities of views and ...
In my experience, if a result is needed in multiple places in the user interface, this suggests to me that the method for calculating it is a universal business rule, and therefore that rule has no business being implemented in a single presenter: it should be part of the domain model, instead. At that point, no communication between presenters is needed, ...
The method could be part of the presenter, it could stay in the model, or it could be moved to a separate helper or controller class. None of these placements is always "better" or "best practice". Which to choose depends on factors like how complex is that operation, does it only make sense in conjunction with those view/presenter operations, do you want it ...
In an MVP model, the presenter acts as middleman between the view and the model.
In consequence, from the presenter you shall call the model and not short- circuit it by calling repository directly.
The model has to take care of the persistance, including locking if necessary, maintaining the unit of work, caching (e.g.with an identity map) or whatever ...
In my experience it depends on who you ask (but it shouldn't).
I've seen your question asked about MVC, MVP, and MVVM. There is confusion about all three. But why is that?
This is mainly the consequence of a misunderstandings of what the Model is.
For some, the Model is simply a dumb object that holds data. For this interpretation of Model it is clear ...
There are 3 main variants of the same basic pattern:
Model-View-Controller: The granddaddy of them all. Originally defined with Smalltalk
Model-View-Presenter: Variant created primarily to deal with the limitations of Windows Forms architecture. Suits technologies where the UI cannot directly bind to the model
Model-View-View Model: Variant created ...
Both ways will work, so they are both correct. And none of them is "better" in general, the first one is simpler, but the second one allows some things the first one does not, so you have to analyse your requirements if that additional complexity pays off.
MVP is a design allowing you to test the presenter and mocking out the view easily. It will also allow ...
I would sort them by logical grouping first, then by category second
So all your Login objects would be in one area, all your Customer Management stuff in another, etc
Some examples would be
The correct answer is (drum roll please) it depends. Are you using a UI framework that supports sorting natively? Are you sorting over a large sequence that would be best performed as a database operation? Does your UI framework support sorting through the database (e.g. IQueryable support in many .NET UI toolkits).
There are multiple approaches to MVP. ...
There are many approaches in the real world about this. You are asking a very broad question so my answer will be a bit general.
Of course there is a concept of design in agile. There is normally no concept of up-front design, but systems are designed as you go and, of course, legacy systems have a design.
Strictly speaking, you should do the bare minimum ...