First, I would encourage you to not bind your EF models to your views, but instead create separate ViewModels. This abstracts your domain from your presentation, and also prevents unused data from going to your views. Most importantly, it will prevent unintended data from being posted back to your controllers, in the event your accepting your EF models in your action methods.
Secondly, I would also encourage you to remove some of the filtering/mapping logic from your views. Your controller should be responsible for preparing your ViewModels and sending exactly the data that your view needs. Your view shouldn't be doing this at all -- it should just take the ViewModels exactly as they are, and present the data to the browser.
Now regarding your exception, this is likely due to the fact that TextAreaFor()
it is expecting a model property from a lambda, but you are giving it a single value (see documentation). For example, you can't do this:
@Html.Bootstrap().TextAreaFor("My comment.")
But that's basically what you're doing by giving it a Comment value from the result of a Linq query, vs. giving it the property (m => m.Comment).
I suggest refactoring your ViewModels to use simple data types, and hydrating these ViewModels in your controller, like I mentioned above, doing all filtering and mapping before handing them off to the view.
Once you do this, if you need to render multiple AnswerModels, then these should have corresponding EditorTemplates:
@model AnswerModel
@Html.Bootstrap().TextAreaFor(m => m.Comment)
Then in your view, you can simply render out your multiple answers for your main view like this:
@model MainModel
@Html.EditorFor(m => m.SelfEvaluation)
(See this answer on more about MVC templates and looping through them.)
You can see that this makes your views much cleaner and easier to follow.