Based on the presented information, a simple interface will cover your reusability needs.
Note: One could argue about using a base class (abstract or not) instead of an interface. I suggest erring on the side of interfaces in languages which don't support multiple inheritance or when the needed contract does not require a base implementation.
For example: BMW has a table Motor with a field named 'cc' (for engine displacement), but the Ford stores the same thing in a field named 'cu' in a table named Engine.
You've established here that while the data is stored differently, you expect to handle the same data (once retrieved). The retrieved data is not specific to a given manufacturer and you can therefore create a single data entity to represent it:
public class Car { public string Make { get; set; } public string Model { get; set; } public int CC { get; set; } }
This is just a basic example.
However, the fetching of the data is different per manufacturer, so your repositories will be distinctly different. Nonetheless, they share the same reusable expectation: retrieving cars. This is why we define the interface:
public interface ICarRepository { IEnumerable<Car> GetAll(); }
You can of course expand this interface, e.g. GetByEngineCC(int minCC). This depends on what you need.
This can then be implemented by your manufacturer-specific repositories, which individually have different private logic to fetch the needed data.
public class FordCarRepository : ICarRepository { public IEnumerable<Car> GetAll() { // fetch from the Ford tables } } public class BmwCarRepository : ICarRepository { public IEnumerable<Car> GetAll() { // fetch from the BMW tables } }
This ensures that you can write report generator logic that works for all possible manufacturers. For example:
public void PrintReport(ICarRepository repo) { var cars = repo.GetAll(); foreach(var car in cars) { Console.WriteLine($"{car.Make} - {car.Model} - {car.CC}cc"); } }
Notice how this reporting logic works for all manufacturers, provided that these manufacturers' repositories implement the needed interface.
This is the core principle how to handle internally different implementations (i.e. unique data fetching) but with externally common handling (i.e. generalized reports). You can now add new manufacturers into the mix by creating additional concrete repositories but no other code needs to be changed, which is the desirable goal.
On the other hand the prices and sales are stored in one table in case of Toyota but in five (foreign key linked) tables in case of Mazda.
Same story here:
- Assuming the sales data is the same (once retrieved), create a reusable
SalesFigure DTO - Define a
ISalesRepository interface with appropriate methods (e.g. GetSalesForYear(int year) - Create manufacturer-specific sales repositories which implement
ISalesRepository - Write your common logic so that it works with
ISalesRepository objects, not manufacturer-specific repository types.
This way if I have to display a new report for Rolls Royce I just define some rules and I get the results.
This is not a "rule". This is a different implementation. Your underlying idea is correct but I suggest refraining from calling it a rule, because people will misunderstand your intention.
Essentially, all you have to do is add a Rolls-Royce-specific repository which implements the same interface (cfr step 3 mentioned above).
Note: Because you talked about database tables, this example used different concrete repositories using the same interface. In other cases, it might make more sense to implement this interface on the BLL rather than the DAL. But it's the same principle at play regardless of what layer you implement it on.
