I would like to know if it considered good practice in Ember.js to inject the ember data store in a component to be able create/delete records directly from the component instead of bubbling up to the route controller.
Look at what core team are discussing about this topic.
https://youtu.be/y7aHMj6VVJY?t=1127
My take is: it depends. Usually, I will do dumb components mostly which will not access store for doing CRUD operations. In some cases, If the components data do not depend on the URL or not critical data to UI then I will make my component as smart component which can do all CRUD operation.
Ember follows a data-down, actions up convention. Until routable components are released, you can inject the store to components to fetch data however you should persist data at the controller level.
This will ensure that the UI a level above the component remains synced
Related
I have a very simple question: why in a bunch each of the react component uses its state?
I believe that you need to transfer the state of all the components used in the app to the one redux store.
Instead of synchronizing nested parent and childs components states, by the component's key, find its state in the standalone redux store
How to synchronize states from redux-form Field components and cascading DropdownList react-widgets
It depends on how you model the application. For example you can have one reducer for each container component of you application. You still can keep state in your components, but once you need to synchronize this state between components, you dispatch actions with the changes you need and then update the store. So every container that is tracking the part of the state that has changed, will receive those changes.
I'm working on a client/server product. Basically, server will transfer a document to client side to do editing. The client side has full MVC architecture. The document is the model.
Now the problem are:
There are some calculation in the model that need some resources in server.
For performance reason, some part of the model should be lazy loaded.
One example is the image in a document. It didn't load when opening the document, but there is something that load the image, once it loaded it will let the document know and document will recalculate the layout.
My question is if the communication code is part of Model or Controller? Or it belongs to some Context that is neither Model nor Controller? Or the Context belongs to Model?
The model layer should be interacting with data source. In case of client-server setup where you have two separate and independent triads, the data source for client's model layer would be server's presentation layer.
Basically, your client-side's model layer becomes the user of server-side.
It will be better if you can provide some calculation example or document object model.
Let's break through the requirement:
There are some calculation in the model that need some resources in server.
This kind of calculation is better to be put at Model, because it needs resources from server. If you are put the logic at Controller, then:
The Controller need access to server (database), in which break the MVC rule. Another thing is, the Controller now know the connection (either string or physical file storage). If you add another adapter / bridge, then it is additional effort
The calculation cannot be applied to other UI-implementation. Say in .Net, you put it in Asp.Net MVC and add the calculation at Controller. If sometimes you need to support desktop UI, then the calculation cannot be used as is (because already being tainted with controller actions, added useless web dependency, etc)
For performance reason, some part of the model should be lazy loaded.
I'm not sure about your objective with this. But let we go through this. I'm assuming that you has Header model which has List of Details that need to be lazy loaded. This can be achieved with 2 approach.
First approach is to implement lazy load at the Details property, and second approach is to retrieve a list of Details given by specific Header or id, retrieved from the repository. Both of them are resulting the same. IMHO I like the second better, because with later solution, you can reuse the repository in other module, and enable you to select Details without specific Header. The placement, I believe it should be on Model.
I may misunderstand the requirement though.
I have setup a very basic first application where I can add and remove names from a list, which are then added/removed from a database using a RESTful API, using Ember-Data with the default REST Adapter.
I'd like to implement some form of polling/long-polling so my interface remains up-to-date.
So for example, lets say I open my 'list' in two tabs, delete a few names in one tab - I'd like for the changes to then (eventually) show up in the other tab.
How can this be done easily with Ember?
What you want to do is really a job for WebSockets, which would allow you to push changes to your models from the server to the Ember app whenever they happen. This type of approach can easily take care of keeping thing in sync between tabs. I would recommend checking out Socket.io, which has a great client-side JS library and many server side libraries. By default it will try to use WebSockets, which are better than long-polling, but will degrade to long-polling if it needs to. This might force you to change a bunch of your application set-up, but I would consider this the "right" way to go.
we are planning a REST api for our application and are trying to make
a decision on if we should implement separate controllers for the REST
functionality or not.
We could use the withFormat{} in our current controllers but
separating the REST functionality in different controllers feels
somewhat cleaner..
In that way we can build our API seperate from the current controllers
and we could even take the REST controllers into another application
etc.
Any thoughts on this subject? Any real world experience in what the
best practice would be?
We recently faced the same decision and we decided to go for separate controllers for the REST API.
Advantages of separate controllers include cleaner/clearer controller actions and the possibility to support different versions of the REST API later on.
We also would like to keep the option to host the REST API on separate server instances open. These servers would use exactly the same .war, but with different configuration settings for the feature toggles.
A disadvantage of separate controllers might be the DRYness of the controller code. Although this should be limited, since IMHO you should keep the controllers as thin as possible and extract shared logic to Grails services or helper classes.
I will work with grails soon, but so far i have little experience with it. But in web apps i worked, we always left webservices separated from the controller code. We also separated REST from SOAP. Common methods for them would be in service layer. It, indeed, felt cleaner. We didn't had to insert a lot of ifs in the methods
I would, for a given resource, use one controller that interfaces with a service layer based on context (the media type received or requested -- SOAP, JSON, XML, etc.) This way, you have a truly uniform resource identifier that can accept and return various media types and the controller won't need to know anything but what method the user wants to perform on what resource and what media type is involved.
For instance, maybe the service layer returns objects that have methods such as 'toXml', 'toSoap', or 'toJson'. Then you can just ask the service layer to do whatever and use a switch statement on the requested media type to either return the requested information, or by default throw a 406 Not Acceptable status code. For unsafe or idempotent transactions, the object may have constructor or factory methods for a given media type and then you just ask the service layer to do whatever with that object.
We are developing a web application. We want to possibly reuse the work we do here for a different application that will use the same database, and use the same business rules for reading and writing to said database.
Which design would be more correct
Having the UI call web services, which would use business objects containing the business logic, which would talk to the data access layer.
Have the UI use business objects containing the business logic, which would call web services, which would then talk to the data access layer.
Have the UI user business objects containing the business logic, which would talk to the data access layer.
Don't mix logical design with physical design. Logical design operates over layers and physical design - tiers. Web Service is not a layer. It is simply a tier.
In logical design there is standard approach: UI layer-> BL layer -> DAL
In physical design all layers can reside within one client-side application connecting local database, or can be distributed over the remote tiers. But for distributed applications usually is added one more layer: Application layer, which hides from BL layer communication over the wire.
I would say the 3rd one. I tend to think of web services as another presentation layer.
Think of it this way: you have a web UI, which calls your business layer code to do things like create a new user (User.Add), find all products that match a given description (Products.FindByDescription), etc.
You can now re-use that same business layer code to build a set of public-facing web services for 3rd parties to make use of. There can be a method which adds a user - that calls your internal User.Add() method, another one to find products, etc..
What you get is a parallel set of presentations/interfaces to the same underlying data and business logic.
Behind the scenes (totally out of the scope of web services or UI layers), the business layer calls a data access layer that takes care of physically querying the database. If you were to change to a different DBMS, you should ideally (and in theory) be able to rebuild the data layer for the new database and have everything simply work.
Your business layer contains the rules like a username has to be 4 to 15 characters long; users are only allowed to search for and load products that are at a store they have access to; etc.
If you decide to change a business rule - like a user is allowed to search for products in any store in their state - then you change it in once place, and don't have to touch the web service or UI to make it work.
From your description, you haven't provided a reason why you would need the use of a web service layer. Assuming your database is reachable by your UI system, i.e. within the same network behind your firewall, a basic business-object layer that your website UI code (server-side, I'm assuming) will employ meets your requirements.
Bring in a web service tier when the distance between your UI system and your data layer starts to cross boundaries that a Data access layer or Business logic layer would begin to encounter difficulties.
In terms of the design being "correct" or not, it's not really possible to give a 100% answer to the correctness of a design without the full context. What are the requirements (functional and non-functional)? What design goals do you want to fulfill? How important is each goal?
The only goal your question mentions is that you want to reuse the business logic with another application. When I want to reuse the business logic of an application in a standard way I choose web services. So based solely on your one requirement I would say that option 1 ( UI->Web Service->Business Layer->Data Layer ) is a good choice.
Logically, web-services belong in the UI layer. Think of "User" being not only a human but another system and it becomes clear. Maintaining strict separation of concerns between these logical layers will allow you to easily implement and maintain your application.
Check Out: http://www.icemanind.com/layergen.aspx
The way it should go is, you have your UI layer on top, your data layer on the bottom and your business layer in between the two. Each layer can only communicate with the layer below it. So the UI talks to the business layer only...the business layer talks to the data layer only. Your UI should never talk with the data layer and your data layer should never interact with your UI.
Unless you have a reason to use a web service, then I wouldn't.
Do you hear anything about Service layer ? I think you can use a service layer for your transactions and operations and using a facade layer helps you to isolate and manage accessing from UI to data access layer directly or indirectly after visiting the Business layer . it depends on your requirements.