0

I'm starting work on a new personal project and I'm looking to get advice in regards to setting up my classes.

My base class is a User. The User class will have the following general properties

  • User ID
  • User Name
  • Password
  • Address (this will be a complex/value type)

I will then have a Subscriber class which is a User who has chosen to subscribe to a plan that I offer. The Subscriber class will have its own properties in addition to that of the User including:

  • Subscriber ID
  • Plan ID
  • Date Subscribed
  • etc

Is inheritance the way to go here with User being the base class or is a foreign key from the Subscriber to User class the better way? If inheritance is preferred then which method? TPH or TPT?

The plan is to have other classes with the User class acting as the base including Participants and Volunteers.

Thanks!

2 Answers 2

5

My first thought, along the lines of 'prefer composition to inheritance', is that inheritance isn't needed (nor the best representation of the common 'subscriber' system), and that your User class should have a collection of Subscriptions.

The Subscriptions would be basically the same as you've described them, but without the inheritance piece. A particular Plan's 'Subscribers' would be the collection of Users that have a Subscription to the Plan.

Likewise with Participants and Volunteers.

-1

This is 4 years late but just for anyone else asking, design your data model according to the following points:

  • Maintain a Subscription.cs class with details like Currency, BillingPlan, etc.
  • Maintain an abstract User.cs class with details as you've provided.
  • Maintain a Subscriber.cs class which inherits User.cs since all the properties of User.cs are necessary in Subscriber.cs. If only some of the properties are desired, then choose composition over inheritance.
  • Subscription.cs should have a SubcriberID GUID as a unique key and a Subscriber navigational property. Note that this key is not existent in Subscriber.cs.
  • If you have any more classes who will need all the properties of User.cs, let those class simply inherit from User.cs. If your application won't follow this strict inheritance, use interfaces instead and compose as you desire.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.