Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 207
  • Last Modified:

One object/table or two? - Loan/Return model (ASP.NET MVC 5)

Hi all

Just looking for a bit of general advice (what would you do)...

I'm building a fairly standard MVC 5 website with C# in VS 2013.4, using EF6.
User and Book models are setup, with some extra support tables used to generate Select Lists on Create/Edit views.

I'm now at the stage where I need to decide how I'm going to implement my Loan / Return model and logic. These two events occur on different days, and at any given time I'd like to be able to generate views for books that are loaned out (and not yet returned). Books are all unique.

Potential option one -
have separate model classes (and tables) for Loans and Returns, using a foreign key relationship.
Main benefit is I can use Data Annotations (validation) on the Return form as it is separate, without having to add controller action code to ignore null data errors. Separate controllers would be needed for each model class. Not sure if the Return model would have a LoanID or BookID property for the Foreign Key at this stage.

Potential Option 2 -
have one model class/table that contains properties for Loan details and Return details (such as Return Date). Index views to display data should be simpler to code (did I mention this is my first C# and ASP.NET project?) and possibly might have some small performance improvement.
The Loan\Create view would not display the Return form controls, and the controller action would include ModelState.Remove() code.
A new Return view (based on the scaffolded Edit view) would allow for the row to completed later and somehow employ data validation on the Return properties.

Potential option 3
Have some sort of inheritance model, where either Returns : Loans, or bother Loans and Returns inherit from a higher Transactions base class.
tblLoans and tblReturns couldn't be related with a foreign key in this configuration as it creates an infinite loop.

Some other notes that may have an impact:
1. There are only 100 individual books to be loaned out one at a time to ~10 users.
2. Loan and return events also need to be recorded in hard copy - so I would create Index views that list rows where HardCopy = false for easy synchronisation at the end of the week.
3. Complete Loan/Return transactions would need to be counted for periodical statistics reports.
4. Book has a .Status property which will logically related to Loans. i.e. Available, In use, overdue, etc - set in various controller actions)

Current model (based on Option 1) that I'm playing with (some annotations removed for brevity):

[Table(name: "tblLoans")]
    public partial class Loan
        public int LoanID { get; set; }

        public int BookID { get; set; }

        public int UserID { get; set; }

        public int CampaignID { get; set; }

        public DateTime LoanDate { get; set; }

        [Display(Name = "Loan Hard Copy")]
        public bool CommitLoan { get; set; }

        // Return data below - required attributes removed in Controller for creating/editing loans, only required for creating/editing returns

        public Nullable<DateTime> ReturnDate { get; set; }

        public int CompletionID { get; set; }

        public Nullable<bool> CommitReturn { get; set; }

        public virtual Book Book { get; set; }
        public virtual ApplicationUser User { get; set; }
        public virtual Campaign Campaign { get; set; }
        public virtual Completion Completion { get; set; }

// other related partial classes...

Open in new window

If you've been in this situation beofre I'd be interested in what other pros/cons and challenges to anticipate for either option, and which way you would go.

  • 2
1 Solution
Carl TawnSystems and Integration DeveloperCommented:
Logically, it sounds like you would just need a single table to track loans/returns.  Yes, a loan and a return are two separate actions from a user perspective, but data wise, they are simply changes of state on a single entity (i.e. a record of a loan).

You could use multiple models to deal with subsets of a loan record if you need to handle them differently in the application, but data-wise it feels like they should be kept together.  The important thing is to make distinction between how the data elements are stored and how they are used/presented by the application.
Ryan_RIT Systems AdministratorAuthor Commented:
Thanks Carl, that's the way I was also leaning (as evidenced by the current model code ^).
How would one deal with data validation in this scenario: when an item is Returned, those returned fields will be required... they just won't be when the Loan part is initially created.

I thought I could set the database fields to be nullable and use Data annotations in the model (with the return model view errors being ignored in the Create POST action), but with Code First migrations enabled I'm not sure if it's possible.
Ryan_RIT Systems AdministratorAuthor Commented:
Sorry Carl. You're welcome to the points as I followed that course successfully. I just can't seem to find the button in this interface.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now