In an effort to push our development toward a resource-based, CRUD pattern, I'm using RESTful controllers in Laravel. However, I'm running into a need for non-standard methods in these controllers. I often need to add methods to the controllers to handle actions which don't fall into the CRUD pattern.
Does this mean I should abandon the CRUD+REST pattern altogether and pick it back up when a future project can fit into the CREATE/READ/UPDATE/DESTROY pattern? Or does the CRUD+REST pattern still assume that a project will need some non-standard methods in many instances? If so, is there a preferred way to implement them?
For example:
-- Presenting a list view of a given object in the system. Say, a list of users or list of posts.
-- OR Attaching, say, a maintenance script or command to a button.
Neither of these instances seem to correlate directly to a CRUD method.
Related
I am new to coding and I was wondering what is the logical way of representing the interconnections between classes of a system, more specifically the GUI class and the system's classes. Let's consider an online ordering system. In addition, let's consider that we need to make an order in this system. So I imagine that there is a GUI ( after logging in ) and there is a button for make order. So this means that the GUI class will be connected directly to the make order class ( if we assume that there is a class that is responsible for making orders )? Or there should be some intermediate class that should be connected to the GUI and controls the logic of the system ( if user choices make order then this control class deals with the make order class, if user choices to track order then this class deals with the track order class and so on )? I am looking for the most efficient way of writing code.
Edit: In many textbooks, they mention three types of classes that deal with this issue which are boundary class ( GUI), controller class and Logical class, but actually I don't know the exact meaning of the controller and the logical classes types.
MVC is one famous pattern used for this specific purpose. MVC stands for model view controller.
View = Classes responsible for the UI.
Model = This is the business domain where all complex business logic lives. OOP is heavily used here.
Controller = This connects the view with the model. Example - a click on the UI needs to be fulfilled by a model and the controller will connect the UI to that model.
Add REST to this mix which will help UI communicate with Model and the make the model agnostic to type of clients being Web, Mobile or even another server. Angular, React etc are heavily used for UI presentation.
You would needs a persistent layer to persist the state of the model and read it back. Example - A database which can save historical order and read them back. JPA and Hibernate are famous tools for this.
You don't need to deal this raw MVC, rather use one of many web frameworks which will take care of boiler plate code for you. Spring MVC is one such framework in Java world. There are equally famous frameworks for python, node, scala etc. This framework will have standard ways to do REST, Persistence, controller etc. So start from this.
I have read a lot of gwt-mvp questions that are asked here, but since i'm totally new to this design pattern I would like to ask some questions:
[1] The Activity-Place pattern is a different pattern than mvp?
[2] In the MVP pattern presenters contain the logic. Now the logic of the widgets/controls is defined in the Activities?
[3] The CustomPlace classes are fixed (as the Eclipse plugin constructs them) or can i put data/methods and what kind?
[4] What is the use of the Presenter interface inside a CustomView? What data/methods would make sense to add into it?
[5] I want to build an application that will use many data structures that will be saved into a database. I have read some other posts here and I will make the Model part of MVP live inside each Activity. So i think to create each time the data structures of each activity at start and load its values (if necessary from db) and will update the database after the user goes to another view. What do you think about this approach?
Let's start by debunking one myth: Activities/Places have nothing to do with MVP. Places is about navigation, Activities are about "componentizing" the UI wrt Places. On the other hand, MVP is a design pattern, it's about how to organize your code.
Many people are using their activities as their MVP-presenters, but it's not enforced. The GWT team is trying a new approach where the activity is distinct from the presenter (work underway in the mobilewebapp sample if you want to follow what's going on there). You could also have your activity being your view and making use of an "internal" presenter (similar to how Cell widgets work)
A Place is more or less a URL. You can put whatever you want in it. I'd suggest making places immutable though: build a Place, goTo it, make use of its properties to build your UI.
That's about MVP then. This is only needed to decouple your view and presenter, mostly to make mocking in unit tests easier (this is particularly of the view interface though, not much for the presenter one, unless writing a test harness for you views). In some cases, you might also want to use the same view with distinct presenters; they'll all implement the same interface so the view can talk back to them.
How about the closing of the window/tab? I'd rather use a periodic auto-save, or an explicit save button; and implement mayStop so it prompts the user when there are unsaved changes (similar to how most desktop office apps work —e.g. MS Word or LibreOffice—, and GMail if you try to navigate away before your mail draft is auto-saved)
The Activity-Place is an implementation of the pattern. Google introduced gwt-mvp pattern at Google IO, but only provided it's implementation as part of GWT about a year later.
Yes Activities contain business logic. No, widgets/controls usually do not contain any logic, they just fire events based on user action. The logic that acts upon those events is written by user and resides elsewhere.
I don't use Eclipse, so wouldn't know about Places generated by it. Normally custom Places can contain custom fields and methods. For example they can contain custom place token arguments, i.e. if place token is "#place:id1", than your custom Place could contain field holding this argument.
When View needs to call/access Activity, it does so via Presenter, which Activity implements. For example when user enters all data in a for and presses submit, then you could have a method in Presenter named submit(formData).
Preparing/loading data in activity.start(..) is a normal way of doing things. If particular activity is used a lot, then you might consider caching the data if appropriate.
I have an ASP.NET MVC 2 application with some complex business rules and I'm trying to decide where to put specific logic.
The logic happens when creating records, based on certain fields of that record other records need to be created.
I'm currently using the repository pattern with an ORM and the easiest place to put this logic would be in my repository class but I feel like this is a pretty feeble location to have important rules, I would put it directly in my partial model classes that have my validation and metadata but I then have to call methods within my controller or repository and that may be extending too much knowledge about implementation to those layers.
What are your best practice tips for me?
Thanks!
You could have a service layer between the controller and the repositories. The repository performs simple CRUD operations with your model. A service method could make use of multiple simple repository calls to compose a business operation. This business operation will be exposed to the controller.
This seems like an elementary question, but after a lot of searching around I can't seem to find a straightforward explanation:
If I'm building a web application that is going to be accessed largely through a web browser, but that will also support some API requests in a RESTful way, should there be a large degree of separation between the two?
On one hand, it seems a large amount of the functionality is the same, with identical data presented in different views (HTML vs. XML/JSON). But on the other hand, there are certain things I need to present to the browser that doesn't quite fit a RESTful approach: how to get an empty form to create a new instance of a resource and how to get a pre-populated form to edit an existing resource.
Should these two different methods of accessing the system by funneled through different controllers? Different methods in the same controller? The exact same methods with a switch for view type?
Your core controllers don't have to change, but that doesn't mean you can't have some extra ones solely to support you UI. For example, both of the Form examples you have can be unique to the Web API. Your entry URIs can certainly have links to those pages for both the machine and user interface, just don't expect the machine users to actually use them.
Also, if your machine clients are simply XML/JSON, then those representations don't need those links at all to the forms, since they'll not use them, and they don't "work" in JSON/XML anyway. You can manage that through Content negotiation.
I am trying to refactor my Catalyst application and I would like to introduce a common base class for my controllers. This base controller would load some data and put some other data into the stash for every request. I have got some trouble getting to the stash. Simple solution would be to implement a default auto action in the base controller. This works, but I have to remember to always call the super auto in the derived controllers. This is easy to forget, is there a better solution? In other words: Is there a simple way to tap into the request processing that wouldn’t be so easy to break in the derived controllers?
I don't think you need inheritance in order to accomplish your goal. You might have other reasons why inheritance is a good idea for your application, but it seems as a rule that inheritance is generally overused when other methods of class composition would be more appropriate.
In particular for this case, Catalyst provides for this functionality by allowing you to specify an auto method in your Root controller, which will always be invoked before the auto methods of your more particular controllers for every request. No inheritance required.