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?

Improve this question
9
  • 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
    Commented Aug 8, 2017 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
    Commented Aug 8, 2017 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
    Commented Aug 8, 2017 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
    Commented Aug 8, 2017 at 20:58
  • 1
    Have a look at Automapper. In particular, see this example: codethug.com/2015/02/13/…
    – Robert Harvey
    Commented Aug 8, 2017 at 20:59

1 Answer 1

Reset to default
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.