lately I've been toying with the idea of placing ViewModels in a separate project and populating them in repositories, then handing them to the controller. This could make for really thin controllers.
What is this pattern called?
Hexagonal Architecture has this notion of Adapters, in this case you're adapting from business objects to presentation objects.
However :
If you mean repositories as in persistence layer repositories, it's typically not their responsibility to populate presentation-specific data structures. The persistence layer shouldn't know about the UI.
"Thin controller" doesn't mean you have to place the ViewModels or ViewModel population logic in a separate project. Besides, just because a controller shouldn't contain this logic doesn't mean it can't invoke it. Your controller can call an Adapter object from the same MVC project to convert from whatever it receives to ViewModels, or you could just do the conversion in the ViewModel's constructor.
While #guillauem31's answer is usefull, I think it was missing a bit, and a bit misleading
In short, an adapter is
Adapter
The ‘Design Patterns’ book contains a description of the generic ‘Adapter’ pattern:
“Convert the interface of a class into another interace clients expect.”
In my mind, I'd like to place an adapter between the controller and repository.
He usefully suggests that the adapter can be in a constructor of the viewmodel. I'm not sure I like this, but it seems okay.
I'd really like to keep my models as simple class objects if possible.
So I'd be equally okay with populating the viewmodels in a service layer.
and I guess thats where this question comes in...
Fat model / thin controller vs. Service layer
and here is an approach where the viewmodels are populated using an adapter of sorts
http://paulstovell.com/blog/clean-aspnet-mvc-controllers
Related
First of all i know MVC well and have been using it in project but when it comes to organizing classes and there role i am bit not sure of there proper implementation. Lets take a scenario to proceed with:
A sample which will display All Employee and Department. Data will be fetched from Web Services(Json) and will be stored as offline(Core Data).
So MVC pattern would be:
View will be my storyboard with Employee and Department UIViewController.
Controller will be EmployeeViewController.swift and DepartmentViewController.swift
Model will be Employee.swift and Department.swift
class Employee: NSObject {
var name: String?
}
class Department: NSObject {
var departmentName: String?
}
ServiceManager which will make calls to the web service.
ParseData which will parse the web service response and convert it into Employee and Department objects
CoreDataManager is singleton class to manage CRUD operation on offline DB.
Here are series of question on the above scenario which i have:
Is my understanding correct? Is the structure which i am trying to build follows proper MVC?
How the controller will interact with these components (Service Manager, ParseData, CoreDataManager). Should there be another class which will facilitate the communication between controller and data management(if controller does this then it will a tightly-coupled structure and massive as well).
Should Model be having any code other then property and initialization method as most of the model which i have seen only have property declaration?
Should there be separate UIView classes instead of storyboard to create a proper MVC structure?
Is my understanding correct? Is the structure which i am trying to
build follows proper MVC?
First I will say that "proper" MVC will depend on who you're asking. Its origin is commonly attributed to Trygve Reenskaug when he introduced this into Smalltalk in the 70's. However, his type of MVC was widely different from the bloated versions most commonly used today. The modern way of thinking about MVC is
Model = mostly a dumb class which primarily encapsulates data
View = whatever we present on the screen
Controller = the big lump of code that does almost everything,
sometimes offloaded by a manager class or two of some sort
Reenskaug, however, would have a model and a view and a controller for a button. For a label. For a field. I'm not saying that is what we should strive for, but there should be better ways to structure a project than using the Massive ViewController pattern (as it is jokingly referred to in the iOS community).
Luckily, there are.
Uncle Bob is preaching Clean Architecture. There are several implementations of this, and various people have made their own implementations of this for iOS, like VIPER and Clean Swift.
How the controller will interact with these components (Service
Manager, ParseData, CoreDataManager). Should there be another class
which will facilitate the communication between controller and data
management(if controller does this then it will a tightly-coupled
structure and massive as well).
Following the principles of Clean Architecture, you should encapsulate these functionalities into layers, in a way that enables you not just to split the code into multiple components, but also enables you to replace them with other components when that is needed. (But yes, at the very least avoid putting all of this in your controller!)
Should Model be having any code other then property and initialization
method as most of the model which i have seen only have property
declaration?
Again, there is not a single answer here. Some proponents of "real" OOP will say that each object should be self-served (i.e. a model object should know how to persist itself), while others extract the knowledge of such operations into "managers". Putting code to persist an object into the object could mean littering persistence functionality into many objects, or require you to rely on subclassing or other solutions to avoid this coupling.
Should there be separate UIView classes instead of storyboard to
create a proper MVC structure?
Storyboard or not does not determine whether you're using "proper" MVC. Also, what kind of class you're choosing (UIView or UIViewController) to represent the View is also not important. Your ViewController can be dumbed down to such a degree that it contains no logic (forwarding the logic that it DOES have to another class, i.e. the Presenter in VIPER).
I would recommend reading about the Clean Architecture and maybe watch a video of Uncle Bob explaining it, read other people's reports on implementing it, and then consider whether MVC is the correct pattern for your iOS project.
I use ASP.NET MVC 3.
I encountered at least 2 approaches for mapping Model->ViewModel on the server side:
inside ViewModel class constructor
inside Controller or designated mapper class
I like first approach the most as the ViewModel property declarations and its mapping are in the same place, easy to maintain and unit-test. Can anybody specify more pros and cons, or other better practice?
ViewModels can exist independently of any database-originated model classes.
I don't recommend putting ViewModel population code inside the Controller as this it not the responsibility of the controller (and is also a maintenance nightmare).
My opinion is that mapping from ViewModel to DBModel (and vice-versa) is the responsibility of the ViewModel, so all of my ViewModel classes implement two members:
public static TViewModel FromDBModel(TDBModel dbModel);
public void ToDBModel(TDBModel dbModel);
The first is a static method that the Controller calls when returning a View. The static method constructs an instance of the ViewModel and sets its members accordingly.
The instance ToDBModel method is passed a constructed DBModel instance (either constructed by the Repository when retrieving or updating data, or constructed by the controller when inserting new data).
HTH.
EDIT: Note that many people swear by libraries such as AutoMapper (which uses reflection and other tricks to automate the DBModel<->ViewModel mapping process). I'm not a fan of auto-mapping because it takes control away from the developer and I don't see it buying me time when I have to learn how the mapper works and how to get it to map non-trivial operations. YMMV.
I'll tend to keep entities and view models separate such that they are unaware of each other. This is to improve encapsulation and minimize dependencies when testing the controllers and mapping itself. See Separation of concerns.
Instead I'd write classes to perform the mappings myself (if its simple) or use AutoMapper and use that method from within the controller. For a larger systems with tens or hundreds of database entities and views, I tend to lean towards AutoMapper. Writing the mapping yourself can become very tedious and error prone. You have to balance the value of you writing it yourself with the value such implementation gives to business. After all, if we wanted to know everything about every framework, we'd each be writing our own version of the .NET framework. :)
That said, there may be little benefit using view models for some systems, especially those where there is a one to one mapping between "fields" in a view and database entities [aka typical CRUD]. I usually cringe when I see that, but it is always an option given a time frame and complexity of the system.
Then there is a case when you use ASP.NET MVC to expose an API. In this case "application/json" and "text/xml" representations of your entities are just "views". View models are often used filter sensitive and unnecessary data from that external presentation. In this case mapping becomes rather complex due to the fact that there may be several representations (and versions thereof) for the same entity. However, this seems outside of the OP.
I'm just getting started with Dependency Injection (DI) using Ninject and am working through my controllers looking to decouple them from my models a bit more.
At the moment, inside of my controllers I am creating an instance of some given model e.g:
var activitiesModel = new ActivitiesModel();
For each of my models that I've been instantiating in this way, should I extract an interface for these and then use DI to tie these things together?
An example of where I'm currently doing this is inside my ActivitiesController:
IActivitiesModel _activitiesModel;
public ActivitiesController(IActivitiesModel activitiesModel)
{
_activitiesModel = activitiesModel;
}
and this is tied together in my global.asax:
Bind<IActivitiesModel>().To<ActivitiesModel>();
Is this the correct way to go about doing this? Should I be creating a new interface for each of my models that is instantiated inside of a controller?
Cheers for any help and nudges in the right direction :-)
It depends on what those models are doing. If they posses data access and manipulation methods then they should be abstracted to weaken the coupling between your controller and data access logic and ease the testing in separation. If they are simply POCO and/or data transfer objects then you don't need to abstract them.
I recently followed Stephen Walther through creating a generic repository for your data models using the Entity Framework with the following link, http://bit.ly/7BoMjT
In this blog he briefly talks about creating a generic repository and why it's suggested to do so (to be clear of friction). The blog itself doesn't go into great detail on how to inject the GenericRepository into your project for that you'll need to download his source code of Common Code. However, once I finally understood the importance of the Repository pattern, and how it makes a difference in the data models I create in ASP.Net MVC I was wondering if I could do something similar to my Controllers and Views?
Can I create a ControllerRepository or ControllerFactory(as I've Bing'd it) and create a generic controller with 5 ActionResults and depending on what I inject into my GenericRepository datamodel (i.e. I have DellXPSComputers, GateWayComputers, HPComputers as a single db datamodel)
And actually have only one controller besides the Generic one I create that will go and grab the right datamodel, and view?
If so, what is the best way to implement this?
You could create a generic controller factory, but I don't see many scenarios why you'd ever want to. Except in your tests and redirects, you'd never be calling a controller method directly (vs. a repository method which you're calling in many places).
Yes! You absolutely can!
I've done it in the past with great success. The result is that you end up with a web application layer surfacing your repos with almost no code (just what's necessary to provide CRUD services for your entities).
Ultimately, you'll end up with something like this in your implementation of CreateController:
Type controllerType = controllerbase.MakeGenericType(entityType, datacontextType);
var controller = Activator.CreateInstance(controllerType) as IController;
return controller;
Wiser men than me would use a IOC framework to inject the types, I'm using plain old reflection and reading the type names out of the route values in URLs like:
http://computer/repo/entityname/by/fieldname/value.html
Good luck!
Our current MVC project is set up to have ViewModels that encapsulate the data from the repository and pass it to the view.
When doing the mapping (In the controller) from Data Object to View model what is the best way to achieve this?
I've seen AutoMapper (http://www.codeplex.com/AutoMapper), but wondered if there was an out of the box solution?
AutoMapper seems to be the accepted (by many) solution.
And I would say, there's no such thing as "out of the box" solution in the MVC world - unlike in Ruby on Rails, for example. Framework is highly extensible but is very thin at the same time, so in lots of areas you have to invent your own "opinionated" way of doing things. Just an example of your situation, I personally have my view models:
Declare static ConfigureAutoMapper()
Have either optional Setup(realmodel) method or optional constructor
ViewModel(destinationViewModelType) is used on actions, and it performs conversion automatically - creating view model, calling Setup or Constructor, or invoking AutoMapper
ViewModel maps are created with predefined ConstructUsing that uses IoC container to instantiate so that view models gets their IoC dependencies if needed
None of the above exist in MVC out of the box. I'd say that MVC only supports ViewData-like usage "out of the box".