I am curious about the role of the repository in the MVVM architecture .If you decide to add repository to your project, will this repository be responsible only for data from database or network ? The question is about SharedPreferences or Files , should I hold the repository responsible for that , or should I keep them in the ViewModel .
From what I understand in MVVM I can say:
Repository should be responsible for all data that your project
component ask for. Whether it's from Database or API.
Let repository grab all data from Database/API/Server/etc. Then you
grab data from that repository.
You can have multiple repository if you need, like API
Repository/FirebaseRepository/RoomRepository etc...
You can merge multiple data sources into one repository, but you need
to handle that manually.
Related
I am currently using Telosys to help me generate Spring JPA Entity Classes from an existing database. So far, I could generate the repository, service, provider directory by using java7-persistence-spring-data-jpa template, but not the entity. Is it possible to generate these entities if you are using the database model (not the DSL model)?
I already figured it out. Looks like each templates serve different purposes in Telosys. If you encounter the same problem with mine, try switching it to this template: java-jpa-entities-T330.
You can explore more java templates here in their github.
As described at the end of this post https://modeling-languages.com/telosys-tools-the-concept-of-lightweight-model-for-code-generation/ each "bundle of templates" is designed to generate a subpart of the final application.
It's a way to manage separately the differents concerns of a project (REST controllers, domain classes, persitence, unit tests, etc)
Currently I'm working on a webapp that has a structure roughly like this:
model
user
robot
service
user
robot
web
controller
user
robot
I'm noticing a lot of redundancy in this structure. Is there any way that I could create a project structure that is less redundant?
The main idea behind folders in a project is to encourage separation of concerns. Each folder should group code into separate functionalities.
Your folder structure seems fine, but I would suggest changing the name of the files so that you know exactly what you're dealing with.
Perhaps more like:
model
user
robot
service
userService
robotService
web
userController
robotController
This way you know immediately that:
model files show structure of entities but no functions or logic
services deal with business logic only
controllers deal with API interfaces
What is the approach if want to add a new attribute to the Product(Model/Data/DTO) in SAP Commerce Cloud and
wanna to access it in Spartacus (using Spartacus ProductService)?
How to introduce the attribute to the Product model in Spartacus and get it populated with the value from the backend?
This question can be seen as a general question how to apply this requirement to all models and keeping the models in sync between backend and frontend.
Thank you in advance.
In order to fetch additional attributes, you can configure the endpoint. See https://sap.github.io/cloud-commerce-spartacus-storefront-docs/connecting-to-other-systems/#configuring-endpoints for more information. There's no need to convert (normalize) the data necessarily, but you could do this as well. This is covered in the same documentation. And you could even replace the standard OCC adapters by a custom adapter if you need to adapt a 3rd party backend.
Once the data is loaded from the backend, it will be stored in the central store, and exposed by the facade without limitation. You might however want to enhance the default typing, in order to benefit from type-safety and not fallback to any. You can do this with the following:
// intro custom typing
interface CustomProduct extends Product {
customAttribute?: string;
}
// use typing for the observed data
product$: Observable<CustomProduct> = this.currentProductService.getProduct()
From a maintenance and deployment standpoint, does it make sense to have one Web API 2 project with many (30+) controllers, or 30+ micro Web API 2 project with one controller each?
I started down the path of having them all in a single project whose structure would look like this:
Comapany.Project.Api (solution)
AccountController
OrderController
InventoryController
//many more here
AddressController
I've come to think this will be problematic when deploying since we just use a file system publish that deletes all files prior to publish. If I make a change to the orderController and have to deploy during the day to production, I will bring down many other services.
I'm about to rework my project structure to something like this:
Company.Project (solution)
Company.Project.AccountApi
Comapny.Project.OrderApi
Company.Project.InventoryApi
//many more here
Company.Project.AddressApi
Then I would have a
Company.Project.Core
This core project would contain some shared code like extension methods, custom exceptions, actionFilters, etc.
I know the answer to this could be very subjective. However, I'm looking for concrete reasons to choose one solution structure over the other. Thanks
I stick with all controllers in one project. I also tend to like to use a single Web API controller per domain / tier / whatever you do to logically break down your application into more manageable pieces so that the amount of controllers can be mitigated.
I've documented my practices on my GitHub Wiki.
We have planned to start an e commerce project using Stripes + Hibernate.
Please let me know if it is good to have admin & user part in same project or two separate ones.
If it is a single project , how do i separate admin side code & user code.
for eg: if i have admin actions in com.ecommerce.adminactions pacakge and user actions in com.ecommerce.useractions package should i use dynamicmappingfilter to direct admin request to com.ecommerce.adminactions and user request to com.ecommerce.useractions ?
-http://myecommerce.com/admin/* - > should always go to com.ecommerce.adminactions
-http://myecommerce.com/ -> should go to com.ecommerce.useractions
or
Should i use #urlbinding(/admin/st.action) in each class (Hard code).
The requirement is they need multistore concept.
Please let me know your thoughts on this.Your thoughts & suggestions will be helpful
Thanks
The Stripes framework does not really influence decisions on how you should organize you're project, or how you should organize your IDE project structure, or even Java package structure or URL structure.
One or more project
Unless you have many developers, keep it all in a single project.
Package structure
A package structure should organize you're Java classes so that you put classes that are logically related (as defined by your architecture!) is in the same package. For example: com.ecommerce.action.admin and com.ecommerce.action.. See also: Properly package your Java classes
URL structure
Typically you want you're URL structure to reflect the logical structure of your website (not the same as your technical structure). To accomplish this, you should not rely on the default URL's but use #UrlBinding. With the annotation you do not hard code links, as all generated links will automatically use the UrlBinding pattern.
Multi store concept
For a multi store concept, you will need to build logic in your application for distinguishing between the different shops. For example by adding a shop id to your URL parameters. Or more sophisticated by detecting the (sub)domain name used and map that to a shop id (You can implement this by using an interceptor).