How can I keep the the logic to translate a ViewModel's values to a Where clause to apply to a linq query out of My Controller?

Question

This same problem keeps cropping up. I have a viewModel that doesn't have any persistent backing. It is just a ViewModel to generate a search input form.

I want to build a large where clause from the values the user entered. If the Action Accepts as a parameter SearchViewModel How do I do this without passing my viewModel to my service layer? Service shouldn't know about ViewModels right? Oh and if I serialize it, then it would be a big string and the key/values would be strongly typed.

SearchViewModel this is just a snippet.

[Display(Name="Address")]
  public string AddressKeywords { get; set; }

        /// <summary>
        ///     Gets or sets the census.
        /// </summary>
        public string Census { get; set; }

        /// <summary>
        ///     Gets or sets the lot block sub.
        /// </summary>
        public string LotBlockSub { get; set; }

        /// <summary>
        ///     Gets or sets the owner keywords.
        /// </summary>
        [Display(Name="Owner")]
        public string OwnerKeywords { get; set; }

In my controller action I was thinking of something like this. but I would think all this logic doesn't belong in my Controller.

ActionResult GetSearchResults(SearchViewModel model){
    var query = service.GetAllParcels();
    if(model.Census != null){
    query = query.Where(x=>x.Census == model.Census);
    }
    if (model.OwnerKeywords != null){
    query = query.Where(x=>x.Owners == model.OwnerKeywords);
    }
    return View(query.ToList());
    }

Answer 1

What you're doing here is using LINQ in place of the more strict OO "specification pattern." Nothing wrong with that, if your application layering allows it (i.e. if you have direct access to the database from your web front ends, which not all architectures do), though you may want to push it into a "service" class rather than performing a lot of query logic in the controller. How strict you want to be in separation of these kinds of things depends on the size and complexity of your application.

One way to introduce a bit of abstraction is to make your view model implement an interface (for example: ISearchSpecification) which defines the properties which can be used in your query predicates. Then, you can create a class or extension method that operates on the interface.

public interface IMySearchSpec 
{
   string City { get; }
   string State { get; }
}

public class MyViewModel : IMySearchSpec
{
   ...implement IMySearchSpec and perhaps other things...
}

public static class QueryExtensions
{
   public static IQueryable<T> ApplyPredicate(this IQueryable<T> query, IMySearchSpec searchSpec) 
   {
        if (searchSpec.City != null )
        {
            query = query.Where( x => x.City == searchSpec.city );
        }
        // ..etc..
       return query;
   }
}

// then, in your controller
var filteredQuery = query.ApplyPredicate(viewModel);

You can also apply paging/sorting logic in a similar way.

Answer 2

How do I do this without passing my viewModel to my service layer? Service shouldn't know about ViewModels right?

Right, view-models are presentation layer objects, so keeping them out of your service layer or persistence layer is a good idea. Also, the controller should be lean and not have much logic, so factoring this code somewhere else is the right approach, I think. Here are some alternatives for your situation:

• Pass your values to your service layer from the controller
• Create a helper class that creates the string for you
• Map your view-model to another class/entity and pass this to your service layer

Answer 3

Usually you would not take a viewmodel as parameter from the view, instead; viewmodels are passed from the controller to the view.

The reasoning behind my logic is that if a large (lots of data) viewmodel is passed from the controller to the view, and than passed from the view back to the controller could become an issue (performance); especially if you do not need all the information in the controller action. I guess you could send a viewmodel created by the view to the controller (a subset of the original larger viewmodel). My understanding of the question was the he wanted to pass the same viewmodel back and forth between the controller -> view -> controller.

From stackoverflow question In MVC, what is a ViewModel?:

The ViewModel may also perform conversions from the type of data that your Model carries to the type of data your View can conveniently work with; this might even mean that the ViewModel does not carry Models directly but other vessels that carry (possibly a subset of) the same information in a more suitable format.

Consider that you could have a Library model that aggregates Albums and DVDs -- the difference between such a model and the corresponding ViewModel is precisely that the Model doesn't care (or even know about) the View while the ViewModel has the express purpose of facilitating it.

Change the parameter to your controller action to a class, like SearchParameters. It is fine to pass SearchParameters to your service layer.