Question

Let’s say you have a concept of “DataPackage” which is physically a zip archive. You need to implement a system to manage data packages, typical scenarios are “import new one”, “remove existing”, etc. There are reasons you can’t store these file in the database.

The question is – how do I divide the concept of “DataPackage” into classes that work separately with its “data aspect” (DB-related stuff) and “file system aspect” (file-related stuff)?

I’m thinking of the following:

// data package concept
interface DataPackage {
  string GetFileName();
  DataTime GetDateTimeImported();
}

// data package manager concept
interface DataPackageManager {
  DataPackage[] GetAllDataPackages();
  DataPackage ImportDataPackage(string sourceFileName);
  void DeleteDataPackage(DataPackage dataPackage);
}

// data package database aspect
interface DataPackageData {
  int GetId();
  void SetFileName(string fileName);
  string GetFileName();
}

// data package database manager
interface DataPackageDataManager {
  DataPackageData[] GetAllDataPackagesDatas();
  DataPackageData CreateDataPackageData();
  void DeleteDataPackageData(DataPackageData data);
}

// also, similar 2 classes for DataPackage's filesystem aspect
// these would be responsible for copying files, removing files, etc

Is it normal design in case the problem I’m trying to solve is “as-simple-as-possible” implementations for both DataPackage and DataPackageManager? I currently have all this stuff implemented in DataPackage and DataPackageManager and thinking whether what I’m proposing here is better than what I have.

Answer 1

How about encapsulating DataPackage into two different classes, one for database related stuff and other for File related operation.

DBDataPackageManager {
DataPackage dataPackage;
//get, set, remove, modify etc etc
}

FileDataPackageManager {
//file operations on DataPackage object.
}