In an MVVM architecture, where should the model be? Does the client have to have a seperate model (which we might call client model) or can we consider the web API the client is communicating with as the "M" in MVVM.
It might be more helpful to explain it over an example. Let's say we have a WPF application for shopping (which is tightly integrated to the server as opposed to a calculator like application). When a customer adds a product to the cart, "AddProductToCart(product)" is called via Web API and returns "OK" on successful operation completion. Then, should we keep a cart object at the client side as well and add the newly added product object to cart? Or rather than keeping such a state, should we just update the UI, notifying the customer of the successful aoperation and when the user navigates to another page that requires the knowledge of products in the cart, the client queries the web API and get the fresh data?
If such a model does not exist at the client, then server can return DTO's which can be used as the view model. But otherwise, I guess I will need to keep some kind of a modified version of the business model at the client side(since it would not be right to use the business model entities for the client model). Would that be more in line with the MVVM architecture? If so, is there a best practice for the formation of that model? Because I guess it will need flattening and will requre holding some view specific fields, too.
Related
This is my first time reading about the microservices. Knowing that services is a subdivide system from a whole system which specialize in different domains. What about the data. I assumed all services using tradition db to store their data and data are stored distributed in different domain. What if there are data can belong in both of these domain services, what should I do with them.
E.g. A basket service (handling user shopping cart), and Payment service (handling payment of their order they have placed in the basket).
Maybe this isn't a great example, where do the product information to be stored.
In monolithic application, we have single database which stored the whole business data where each data will have reference to each other.
With the services we tend to ask one question who is source of truth?
In your case user adds item to the cart and there is service which keep tracks of what items the user has added (it may just have a itemid stored)
When this used to moves to checkout, there will be a checkout service which will then ask the cart service about the items in the users cart, apply in the cart logic.
Thing to note is checkout service knows and care about the checkout process and it has no idea where to get the data of the items. Its just calls the right service and get the stuff it wants and apply the logic.
For checkout to payment you pass along userid cartid and other info and payment can make use of these information to bloat the information as it sees fit and return a response back to checkout which may trigger an order service.
So if you see data is always available with one service and when ever you have a situation where you need data, instead of making a db call you make a service call
(Service responsibility is to give you this data with low latency and may be pulling in logic to cache or whatever)
Another point with respect to data is source of truth. For order service, which is called often we tend to keep a copy of all the information related to the order in it (Again we do that, their may be better approaches) and in doing so often during a return flow question which system to trust.You may query an order service to get an address on which order is supposed to be shipped, but this address might have been deleted by the user.
This is where Single source of truth comes into play. This is little tricky, for delivery service source of truth for delivery address is what it gets from order service and not the user service (however order service picked up the details from user service at time of placing orders)
At the same time, during return flow we consider the prices as stored in order service (again a snapshot of what was there during the time order was placed) not necessarily make a call to product service, however for payments we talk to payment service directly to check amount we have taken from the user (There may be multiple inward and outward flows)
So bottom line is
Have one database exposed via one service, and let other service connect to db via this service
Read more about Single Source of Truth. We decided on certain contracts like who is the SSOT for whom (I do not necessarily agree with this approach but it works well for us)
Let's say we have a User entity. Should I have two smaller services (User and Users)? Or one larger service that deals with both a collection of Users and an individual User? If it is the latter, is it best practice to name the service User or Users?
I use one service per entity that houses the collection, methods used by the entity collection controller, and methods used by the individual entity's controller. This works for my team as we follow the repository pattern in our server code. I save the collection in the service because it is accessed often, and parts of the collection are nice to share in other area's like to keep a count in the menu, or create a relational list in another controller. The individual entity is typically only accessed by the controller for the view, and can be disposed of when the route is changed as long as the list item in the controller was updated if the entity was changed.
The only time I used separate services was one edge case where the customer wanted an entity to save state if the route was changed without persisting the entity to the server or cache. The entity needed to be saved somewhere so that was reason enough to create a service for the individual entity.
I do use a separate service per entity to manage http requests. So each entity does have two services, one to manage the collection and all crud+ functionality, and the other for http for separation of concerns.
In the single page webapp I've recently built I'm getting data for my models using Restangular module. I'd like to add real-time updates to the app so whenever any model has been changed or added on the server I can update my model list.
I've seen this working very well in webapps like Trello where you can see the updates without refreshing the web page. I'm sure Trello webclient uses REST API.
What is a proper way to architect both server and client to archive this?
First of all, your question is too general and can have a lot of solutions that depend
on your needs and conditions.
I'll give you a brief overview for a single case when you want to leave REST APIs
and add some realtime with web sockets.
Get all data from the REST -- Sokets for notifications only.
Pros: Easy to implement both server side and client side. You only need to emit events on the server with
info about modified resource (like resource name and ID), and catch these events on the client side and fetch
data with REST APIs.
Cons: One more request to the server on every notification. That can increase traffic dramaticaly when you have a lot of active clients for a single resource (they will generate a lot of reverse requests to the server).
Get initial load from the REST -- Sockets for notifications with data payload.
Pros: All info comes with the notification and will not cause new requests to the server, so we have less traffic.
Cons: Harder to implement both server side and client side. You will need to add data to all the events on the server. You will need to fetch data from all the events on the client side.
Updated according to the comment
As for handling different types of models (just a way to go).
Client side.
Keep a factory for each model.
Keep in mind that you need realtime updates only for displayed data (in most cases), so you can easily
use memory caching (so you can find any entity by its ID).
Add listener for every type of changes (Created, Updated, Deleted).
In any listener you should call some initObject function, that will find entity in the cache by ID and extend it, if there is no entity with such ID, just create a new one and add it to cache.
Any Delete just removes an entity from the cache.
Any time you need this resource, you should return the link to cache object in order to keep two way databinding (that is why I use extend and not =). Of course, you need to handle the cases like: "User is editing the resource while notification about deleting comes".
Server side.
It is easier to send all the model then just modified fields (in both cases you must send the ID of resource).
For any Create, Update, Delete event push event to all engaged users.
Event name should contain action name (like New, Update, Delete) and the name of resource (like User, Task etc.). So, you will have NewTask, UpdateTask events.
Event payload should contain the model or just modified fields with the ID.
Collection changes can be handled in two ways: with add/update/remove items in collection or changing all the collection as a whole.
All modifications like PUT, POST, DELETE are made with REST of course.
I've made a super simple pseudo gist for the case 1). https://gist.github.com/gpstmp/9868760 but it can be updated for case 2) like so https://gist.github.com/gpstmp/9900454
Hope this helps.
We are currently designing an OData compliant entity data model that will be consumed by a mobile application. The team is divided into two; the backend developers providing the OData services and the front-end developers consuming these services.
One point of disagreement between front-end and backend developers is about the design of our main entity. From the front-end perspective, it should look like:
Order:
Order ID
Order Type
Assigned To
Customer ID
Price
Currency
etc...
The Order object will be queried with such URLs:
http://SERVICE_ROOT_URL/Orders?$filter=Order_Type eq 'Inquiry' or Order_Type eq 'Quotation'
http://SERVICE_ROOT_URL/Orders?$filter=Order_Type eq 'Inquiry' and Assigned_To eq 'James7'
The backend developers are willing to add a new field to the Order entity and use this field to understand what the user is querying. Let's name this new field Request Code. With the request code field, the queries will look like:
http://SERVICE_ROOT_URL/Orders?$filter=Request_Code eq '0022' // The orders requiring approval and the current user can approve them
http://SERVICE_ROOT_URL/Orders?$filter=Request_Code eq '0027' // The orders with the open status
Basically, the Request Code is not an actual part of the entity but artificial. It just adds some intelligence so that the querying becomes easier for the backend. This way, the backend will only support those queries that have this request code. The Request Code is also planned to be used in the update scenario, where the front-end is expected to pass the Request Code when updating the Order entity. This way, the backend will know which fields to update by looking at the request code.
I am in the front-end and I don't think Request Code should be included in the model. It makes the design encrypted and takes away the simplicity of the OData services. I also don't see any added value other than making things easier at the backend.
Is this a common practice in OData Services design?
To me, this extra property is inappropriate. It adds an extra layer of semantics on top of OData; which requires extra understanding and extra coding to deal with. It only adds accidental complexity, it leaks a backend implementation detail to its public API.
The OData querying interface should be enough to describe most situations. When it's not enough, you can create service operations to describe extra business semantics.
So, for example, this:
/Orders?$filter=Request_Code eq '0022' // The orders requiring approval and the current user can approve them
/Orders?$filter=Request_Code eq '0027' // The orders with the open status
Could become this:
/GetOrdersRequiringApprovalFromUser
/GetOpenOrders
Also, for the update logic, OData already supports updating individual properties.
So, in sum, don't invent another protocol on top of OData. Use what it provides.
I'm making a Silverlight 4 application with WCF RIA Services.
On the server side (the *.Web project), I have an Entity Model that's auto-generated from a SQL Server database.
On the client side, I have the domain service and proxy objects that are generated by Visual Studio for use in Silverlight assemblies.
I want to add custom properties to the model (preferably on the server side).
Say I have Contact, Company, and Address tables, which are linked by foreign keys (but not necessarily actual foreign key constraints). I want to add a property that will return a Contact's Company's Address object.
I have been attempting to do this by making a partial class to extend the Contact class, and adding a CompanyAddress { get; } property. But I have no idea what I need to do with the new property in order to make it propagate to the auto-generated code on the client side. Are there specific attributes I have to add to the property? Do I have to register it somewhere so that the code generator will know about it?
Does this have to be a Navigation Property or can it be something simpler?
And is this even the best way to do things, or should I give up on extending the server-side model and just do it on the client side? (If I do it on the client side, I face the problem of not having access to the context object inside the individual Entity-derived classes.)
I have never used Silverlight or RIA services but I guess it will be quite similar. When you create EF model and you have entities related by foreign key (there has to be relation), each entity related to other entity will contain something called navigation property. So in your scenario Contact should contain property named Company and Company shoud contain property called Address. You can isntruct EF to load those navigation properties by using Include on ObjectSet or by lazy loading (not good idea in WCF). Than if you send Contact by WCF to the client, Company and Address will be send as well.
Your approach has one big problem. Your property contains only getter - such property is not serialized.