4

I have an existing project running in the ASP.NET technology. Currently, the entire business logic calculation is happening in the database sProcs (MS SQL Server). And at times, the application becomes slow when it being used by plenty of users during the busy time of the day.

Now we want to move out some of the business logic processing away from the DB and perform it in the business layer (C#) side. I am trying to understand how do i get the data from the database and perform some calculation on it and then again save the furnished data back to the DB.

I can get the raw data from the DB , then serialize into the XML and then pass this XML to the BL layer. In the BL layer, XML will be De-serialized into the strongly typed business objects. And then using the Linq-to-Object, i can perform some operations (such as Sum, Avg etc) on it.

Please advise with your suggestions.

  • 2
    This seems like a broad question. You may want to look into a tutorial on how to save data. – JeffO Feb 17 '17 at 16:24
  • 3
    Is the conversion to XML necessary? Couldn't you convert the raw data into a strongly typed business object or DTO, pass it up to the BLL? Then, run your operations and then pass back down to save? – asp316 Feb 17 '17 at 17:37
  • 3
    Do you have a diagnostic on why it is slow ? Is it the amount of data handled, the concurrency (leading to contention), incorrect isolation level on the database or sheer lack of power on the hardware (DB hardware worse than the webserver hardware) ? If you don't diagnose properly what's wrong, you may be solving the wrong problem here or even worse, you can be buying another problem for you. – Machado Feb 17 '17 at 17:55
8

Be careful! If I understand you correctly, what you describe is going to be a lot slower.

Aggregate operations like Sum, Avg etc. is pretty fast if you run them in SQL. They will only be slow if they operate over very large datasets. If you have a large dataset then it will be much slower to transfer the whole dataset to a client and perform the aggregate operation there. Serializing to XML and deserializing again is going to make it even slower.

You should probably investigate carefully why you are having the performance problems in the first place. You might have some locking issues or perhaps inefficient queries.

I think the term business logic is often to broad. Some forms of business logic belongs in the database, and some forms belong in the client. All business logic which perform joining, filtering or aggregating over data belongs in the database. You will just get horrible performance problems if you move this to the client.

  • Saying "is has a potential to become slower" would be fine. Saying "is going to be a lot slower" is an unsolicited and probably wrong assumption. The only part in your answer which is IMHO fine is the recommendation to "investigate carefully" why there are performance problems. – Doc Brown Feb 18 '17 at 0:44
  • @DocBrown: Obviously there is not enough detail to say it definitely will be slower, but why do you think it is "probably wrong"? – JacquesB Feb 18 '17 at 12:36
  • 2
    When guessing around things like performance, there are much more wrong possible guesses than right ones, that is why it is important to measure. For example, if there are hundreds of clients accessing the same database, even if a single operation runs quicker on the db server than on one client, it could scale better if the operation is moved to the clients than letting the server do this for 100 clients. Or, it won't make a noteable difference because the bottleneck is in a completely different place. In both cases, a prediction like "will just get horrible performance" would be wrong. – Doc Brown Feb 18 '17 at 12:51
  • @JacquesB - Thanks for your suggestions. Currently, around 95% of the business rules are getting processed in the sql side. I have multiple applications with which data has to be moved around. That is the reason, i was thinking of utilizing the XML data|metadata. – Karan Feb 20 '17 at 8:35
  • I have different database for each client & the data processing is taking hell of a time because of the data size. The new design will attempt to move (may be 50%) some processing into the C# code. – Karan Feb 20 '17 at 8:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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