0

I am in the process of refactoring some (extremely) tightly-coupled, legacy VB.NET interface code which transfers data between a SQL Server database (using direct calls to ADO.NET and stored procedures) and a SAP R/3 system.

My first concern has been to get the code under test and, so, I have been able to separate the business logic from the RFC calls to SAP on the one side. Now I want to be able to inject the main business object with either a dependency to a class that will handle the database calls or a mock object so that I can unit-test the business logic separately from the DAL.

However, I am not clear on the best way to separate the database calls from the business logic. Is there a best practice or pattern that could guide me here?

Michel Keijzers
  • 15,025
  • 28
  • 93
  • 119
David Brower
  • 2,888
  • 2
  • 25
  • 31
  • You may want to take a look at some of the general questions that have already been posed http://stackoverflow.com/q/1503584/299327 and http://stackoverflow.com/q/1090521/299327. I personally prefer injecting the interface into the constructor and using it for the lifetime of the class. – Ryan Gates Jul 03 '14 at 14:55
  • Re:"injecting the interface into the constructor " - that's what I would like to achieve. I am just thinking about the **best** way to model the class (which I can then mock) that will contain the database calls. – David Brower Jul 03 '14 at 15:27
  • 1
    I would recommend that you model it based on how you would like to call it. Forget about the database for now, create an interface and use that in your business layer. – Ryan Gates Jul 03 '14 at 17:16
  • I'll do that. Thanks, Ryan. – David Brower Jul 04 '14 at 08:45
  • 1
    No problem. Once you get more a substantial and working solution make sure you post it as an answer. I know myself and many others have struggled with the same scenario. – Ryan Gates Jul 04 '14 at 16:10

0 Answers0