Is there a reason to avoid tight coupling to a model class?

Question

By this I mean something like Student, which is modeling a Student table row:

class Student
{
    public string lastname;
    public string firstname;
}

It doesn't make sense to me to program to an Interface or even inherit from a "regular" class. I really don't see where I have to worry about coupling here, if I am using something like the Entity Framework (or any other abstraction to the database), where I have a Separation of Concerns already.

Sooner or later I have to know which class I am supposed to be using, and I'm having a hard time seeing any problems I might have in the future with tight coupling to the model class.

Even if I have,

class Student extends Person
{
    public string lastname;
    public string firstname;
}

So later I can do,

public function myFunc (Person somestudent)
{
    Person myPerson = somestudent;
}

I do not see the benefit as I want to know if someone is really a Student object.

I have seen these,

How to manage coupling in model classes

Shared database vs tightly coupled message model

C# - Data-Driven Design & Coupling - Mother may I? (did not seem to resolve the issue)

Answer 1

The primary reason for using an interface is Liskov Substitution principle. If you adhere to LSP, you can substitute a different class for different scenarios, e.g. for unit testing.

That being said, if your model is merely a simple data container-- it contains only read/write properties and has no behavior-- there is very little to substitute. Your unit testing code can just use the original model instead of a mock or stub. It isn't absolutely essential to use an interface with this type of model. I don't.

Answer 2

Coupling, like everything else in computing, is a tradeoff. You want loose coupling when it will benefit you. The coupling that occurs between your application and the .NET framework, or packages downloaded via Nuget, is some of the tightest coupling there is.

In line-of-business applications, loose coupling comes into play when you want to go beyond simple CRUD operations to actual business processes. Absent that requirement, you might as well just use the generated DTO's that Entity Framework provides. Entity Framework even gives you "unit of work" capabilities for free.

Consider, for example, an invoice. An invoice is unavoidably a business artifact. You don't store customers or products in invoices; rather, you look those things up from a database, and then reference them by ID. Your business layer translates between business objects (the invoice) and CRUD operations (people and things; entities). In so doing, it typically makes a ViewModel object that contains all of the entities required for the invoice. That's' where your loose coupling comes into play.