2

I am trying to develop business application with separated backend (persistence, business logic, server side workflows) and frontend (presentation, some business logic) which communicates using REST API/JSON between themselves. This architecture is acknowledged as good one in Is it normal design to completely decouple backend and frontend web applications and allow them to communicate with (JSON) REST API?

In my case I have choosen Java/Hibernate/Spring for backend and Angular2/4 for forntend, but my question is relevant for any other combination of technologies, e.g. with Laravel backend and Bootstarp frontend, with .NET EntityFramework backend and may some other JS SPA related frontend.

As I am proceeding with my application I am stuck with one huge problem: my backend retrieves entity graph consisting from Invoice/InvoiceLine/Good entities in obvious manner. I can convert this graph into JSON using standart libraries (e.g. Jackson in Java) and I can send them to frontend. Frontend does processing of those JS entities and sends them back to the backend. Everyting is fine so far. The reattachment of received entities to the persistence context is the core problem of my question - how should I do this, is it possible at all to do smart reattachment of full entity graph and why there is no widespread support for this scenario in libraries (Hibernate and so on)? The core issues is reattachment of entity graph. It is possible to reattach one entity without problems, every book on relevant technologies provides examples. The problem is - full entity graph can be huge. And reattachment should detect any possible sequence of modifications of this entity graph. E.g. some InvoiceLines can be addeds, some deleted, some maybe updated, some can have changed prices, some can refer to fully new Goods and so on, so on.

So far I know only one technology that can mimick completely clearly and rigorously such "reattachment" and it is Delphi ClientDataSet with CachedUpdates feature (I guess, that old school Microsoft also had DataSet componend): this feature records every modifications that are done on the graph of connected ClientDataSets and upon Applying CachedUpdates to the database, all the recorded updated (be they inserts, updates or deletes) are applied one by one to the database.

So - current reattachment technologies (for Hibernate, for EntityFramework, for Yii ActiveRecord, for PHP Doctrine/Propel, etc., etc.) do not have this notions about cached updates, about sequence of modifications, so - current reattachment technologies compare only end-product with the current database state and somehow infer or do not infer really complex sequence of SQL statements. My experience is that reattachment technologies simply can not do this and there is no way to control this process, they do not scale beyond work with single entities or list of entities.

So - how should I solve the reattchment problem in the web application that is made from backend and frontend applications that communicates with REST API/JSON and sends among its part complex and ever changing entity graphs?

TomR
  • 1,003
  • 1
  • 9
  • 17
  • 1
    You don't re-attach entities. Instead, you read the entity from the database, map your changes from the JSON onto the entity, and then call SaveChanges() (or its equivalent) in the DAL of your choice. – Robert Harvey Aug 08 '17 at 20:50
  • It is obvious how can I map changes of one entity to the current state of the database. But how can I mape entity graph to the current state of the database? By "reattachment" I mean every technological process that does this mapping and saving. My question was - there is no technology support for this process, so - how should I reachitecture my application or how this problem is solved by other more experiences developers and software architects? In general case - for arbitrary graphs. – TomR Aug 08 '17 at 20:55
  • 2
    You map an entity graph one object at a time. If that doesn't suffice, then consider the possibility that your design is too complicated. For ways to ease the mapping process, look at libraries like Automapper. – Robert Harvey Aug 08 '17 at 20:56
  • "Invoice - Buyer - set of InvoiceLines - Good" - such entity graph is so common. There is no room for simplification and yet there is no general technology that can do mapping for such graphs. Besides - I guess that real business applications have really more complex object graphs because our world is complex and OO models and implementation of those models should reflect this complexity. There can not be simplification, such software is not usable in complex world. – TomR Aug 08 '17 at 20:58
  • 1
    Have a look at Automapper. In particular, see this example: http://codethug.com/2015/02/13/web-api-deep-dive-dto-transformations-and-automapper-part-5-of-6/ – Robert Harvey Aug 08 '17 at 20:59
  • You need to define specifically what you mean by "reattachment". In some of the libraries you mentioned, like Doctrine and Hibernate, attachment has very specific meaning so it is not clear what you are talking about. – RibaldEddie Aug 08 '17 at 23:44
  • For example, are you talking about de-serialization, like how do you take the JSON and turn it into a persistable object with needed domain behavior? – RibaldEddie Aug 08 '17 at 23:45
  • No, I can do deserialization form JSON into Java Entity Graph without problems. I don't know how to save this Entity Graph in DB/PersistenceContext? Should I call entityManager.merge(root_entity_invoice)? And is this merge capable of saving entire entity graph with all the gathered inserts/deletes/updates (e.g. of invoice lines and chained entities)? – TomR Aug 09 '17 at 05:59
  • Is this a new entity object graph or an existing one? – RibaldEddie Aug 09 '17 at 15:59

1 Answers1

1

You said "Frontend does processing of those JS entities and sends them back to the backend." I suppose that You are returning full graph. Why don't You return json patch (https://www.rfc-editor.org/rfc/rfc6902) to backend (I know that EF and WEB API can handle json pach I'm not sure about others ORM-s e.g. spring data and rest) Other option is to track changes on client for each entity in graph.

Community
  • 1
Mirza
  • 111
  • 3