CODEWITHSUNDEEP
c#.net
walter
walter

Reputation: 823

Best practices on how to separate run time properties from other properties in class

I have object that is serialized into db.

The question is where to keep run-time properties (like last run time, etc.), in same class or separate class or derived class? What should be the best practices in this scenario?

Updated: For example: Object Train

properties: type, weight, height, speed etc

run-time: travel start date, travel end date

Upvotes: 3

Views: 160

Answers (3)

Will
Will

Reputation: 2532

I would use the following class structures: ("public / private" and properties excluded for brevity)

// describes the run schedules
class RunSchedule {
  int RunScheduleId;         // only used by DB to uniquely identify record, never seen by user
  int RunId;
  DateTime StartTime;
}

// describes the runs, so repeat runs do not duplicate this information
class Run {
  int RunId;             // only used by DB to uniquely identify record, never seen by user
  string Name;           // unique run name as known by everyone, eg. "Chicago express"
  Train Train;
  string StartLocation;
  string EndLocation;
  TimeSpan Duration;
}

// describes the train-specific information, without duplicating anything
class Train {
  int TrainId;        // only used by DB to uniquely identify record, never seen by user
  string Name;        // unique train identifier as known by everyone
  TrainType Type;
}

// describes the train-common information, shared across trains of the same type
class TrainType {
  int TypeId;         // only used by DB to uniquely identify record, never seen by user
  string Description;
  double WeightMetricTonnes;
  double HeightMetres;
  double SpeedKms;
}

Also, as I've shown, when talking about things like length, speed, weight etc, please make sure you state the unit. I'd probably also add a status to these, so obsolete runs, trains, etc, can be hidden during data entry.

Upvotes: 0

Marc Gravell
Marc Gravell

Reputation: 1062770

Looking at the example now added I would say that you should move those out, and instead use encapsulation - i.e. A TrainJourney class that has the "runtime" properties (that really isn't the right term here) and a reference to a Train instance that is your data entity.

Adding extra properties (commonly in a partial class) to a data entity is OK as long as they tie directly to the data entity. This typically means calculated values, deferred/cached values, interpretations (IsOpen rather than Status==Status.Open etc).

In your case, the extra properties relate to unrelated concepts; by separation of concerns you are confusing things by mixing that into your Train class. So: don't.

Upvotes: 3

Anders Abel
Anders Abel

Reputation: 69260

I assume that you are using some kind of standard serializer. They do often provide the possibility to mark what properties are serialized through the use of attributes. Mark only those that should be persisted as part of the serialization.

Besides that I think that a solution where you use serialization for saving to database should be really thought through. There are some cases where it is relevant, but it is often much better to have the objects' properties mapped to columns in the database.

Upvotes: 3

Related Questions