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)


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.

| improve this answer | |
  • I thought my model is always supposed to be a simple data container. – johnny Aug 15 '17 at 16:19
  • 1
    It is. So, interfaces not needed. – John Wu Aug 15 '17 at 16:25

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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