Since this question seems to be pretty subjective, I'm posting it here.
Let's say you're writing your own version of Stackoverflow using ASP.NET MVC, so there are classes like
User, etc. Since you're lazy, you decided to use entity framework. So, all the classes mentioned above have navigation properties:
Question knows its
Answer knows the
User who posted it, etc.
You've read a lot of Martin Fowler's books, so for sure you're going to have a service layer to implement all the business logic there. You're going to use ASP.NET MVC only for the UI and application logic related functionality.
There are 2 questions:
- Will you directly expose objects of
Answerand others to the controllers?
- Will you do the same for views?
I'm basically neither going to provide a REST API to my application, nor I'm too conservative to just have any fears like "hey, MY VIEW is aware of what the
Question is, I don't know if it's bad or not, I just don't like it!".
I'm especially curious about the case when the
Question class has a field like
TimePosted and you bind your
PostNewQuestion view to that class. I know that in case I'm not binding that field to any control on the page, it won't be posted, so I'll have that field set to
null when I got the object on my controller side. Is it considered fine or is it bad idea? 2 opposite approaches I'm thinking of are "using DTOs/ViewModels everywhere" and "wtf, less classes is always better!"
What do you think is a right approach? (I know there's no direct answer, so the question in fact is "what should one consider to decide whether using DTOs/ViewModels/Whatever else is good for its app's architecture?")
Also please note we're considering a very simplified clone of Stackoverflow, so:
- It's a web-only project (we're not going to expose REST API or whatever else)
- There are users, questions, answers, tags and search functionality (no outstanding business logic)
- There are like 100 active users per day (no special performance requirements)
- The code should be readable and there should be no surprises or places of special interest in case a new member joins the dev team.
You may also express your thoughts in case any of first 3 points get changed - "the customer now wants our service to allow 10000 simultaneous users" or "we now need to only allow every single user to post once per 15 minutes", etc.