Design guideline for data access

Question

I am working on an App (VB.NET) for my company that retrieves data from a DB about our products (sensors) to make measurements and calibrations.

The DB is part of a software we use, so I have only read access and can't modify in any way it.

At the moment the solution is organized as follows:

• BusinessLogic (DLL)
• Entity (DLL)
• DBAcess (DLL)
• UI (WinForms)
• Test Folder (with a unittestproject for each solution project)

In DbAccess I only have one class which is responsible to retrieve the data and also to parse it, since I need to do some work, to prepare the retrieved data for creating my business objects (sensor and measuringCell).

Should I refactor this class in 2 like DbQuery and DbQueryParser or should I declare the "parsing"-method as Shared and leave them in the class?

At this points I always have problems to recognize if I am breaking the SRP, since DbQuery is responsible to retrieve data from the db, but just retrieve data or retrieve data and return it in the way I need it?

Answer 1

Would it make sense to retrieve the data and use it without parsing it?

Would it make sense to use the parser on a data which is not retrieved by DbQuery?

If you answer yes to at least one of those questions, then, indeed, you need two classes. It would mean that retrieving and parsing are independent actions, therefore they don't belong to the same class.

While I don't have enough information about your app, it seems to me that:

• It would make little sense to retrieve the data without parsing it. Things would be different if you had, for instance, a feature which would dump the data somewhere else, or stream it to a separate process which may be coded in a different language and use a different parser and different types.

• The parser, however, is relatively independent from the retrieval of the data. Not only do you need to unit test the parser (and you cannot unit test it if it is coupled with the data retrieval code), but you may also decide later to swap the current database with a different one, or change the technology used to import the data (for instance direct SQL queries vs. ORM).

This would mean that your intuition was right, and it would improve your code to have two classes instead of one.

To further decouple the parser from the retriever, make sure they don't call each other. The parser should have as its input a bunch of DTOs to parse (or a stream if applicable to your case), and as its output a bunch of domain objects which result from the parsing. It belongs to the caller to first call the retriever, and then the parser; the parser shouldn't call the retriever neither directly, nor even indirectly through Dependency Injection.

Answer 2

I would suggest you separate the parsing from the retrieval. I believe your instinct has already guided you. This would be adhering to the Single Responsibility pattern. You may not currently need the parser outside of parsing this data; however, by separating now, If you ever needed to change the way your data was parsed, and/or retrieved, only one class has to change. In addition, you may find the need to reuse the parser in the future and avoid unnecessary code duplication because you had the insight early on to code to the SRP.