2

I have been working on a multi-layer, sale management application developed with WPF and partly refactored with EF6 (long story). The application has some very complex tasks which require multiple calls to the database with obvious performance issues. Say, to issue a customer order the application run a task that requires reading, inserting and updating at least a dozen DB tables or more. There are obvious architectural issues. A refactoring is out of the question because it would require re-writing the whole application. But, I could not stop thinking about how I would deal with an application that requires writing data on so many tables if I had the chance to write it from the ground up.

So, if you had to develop an application with such requirements, and you had to keep EF6 as the underlying technology, my question is: how would you design tasks which required multiple DB calls? I thought of some options:

  • writing data on 1 or 2 main tables, writing the rest of the correlated data on a support table and enable triggers on the DB which would spread the data from the support table to the target tables.

  • calling a single stored procedure which would take care of writing all the data to the target tables (but I am not a fan of writing business logic in the DB)

  • using async calls where possible, but it may end up being complicated to keep things in sync.

  • splitting the task so that correlated data is written in an automated batch at a later time. This option looks to me as the most error-prone.

Any thought?

Improve this question
1
  • 1
    A) Normalize your data; B) Use JOINs when fetching data; C) Use database views to denormalize your data and simplify fetching data; D) Just live with the fact you will need to make multiple INSERTs, UPDATEs and DELETEs. It takes what it takes.
    – Greg Burghardt
    Jun 20, 2018 at 20:28

1 Answer 1

Reset to default
1

You have some data and some business logic that utilizes that data. You have a performance issue moving the data to the logic. The simplest thing would be to move the logic to the data by implementing it in stored procedures in the database. Your other options would be adding additional logic/complexity which doesn't directly address the business problem but rather addresses the technical problems you have introduced by choosing this architecture.

Improve this answer
1
  • Thanks for the answer. Actually, I didn't choose the architecture. The architecture and a good part of the application were already in place when I started working on the project.
    – Marco
    Jun 21, 2018 at 14:32

Your Answer

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

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