I have been doing iOS development using MVVM and dependency injection for a couple of months and I am really happy with the results. The code is so much clear and easier to test. But I have been stragling with a problem which I haven't found a solution that I felt really confortable with.
In order to understand the problem I want to give you a little bit of context. The last app that I have been working was architectured in the following way / layers:
Model
View models
View / View Controllers
Services: Classes that know how to deal with external services like Twitter, Facebook, etc.
Repositories: A repository is class that knows how to interact with a resource of the application's REST API. Lets say that we have a blog application, we could have the users resources and the posts resources. Each of thoses resources have several method. There is a 1-to-1 relation between the resources and the repositories.
When the applications starts we have a Bootstrap class that initializes the app and creates the main view model. We have a restriction that only view models can create other view models. For example in the case of having a view that contains a list of elements (in iOS it will be represented with a UITableView) and the detail view for each of thoses elements that is presented by pushing it to the navigation stack after tapping on the element in the list. What we do is make the view model that is attached to the table view controller create the detail view model. The table view controller listens to the table view model and then presents the detail view model by creating the detail view controller and passing it its view model. So the view controller does not know how to create a view model it only knows how to create a view controller for that view model.
Is the responsability of the parent view model to the pass all the dependecies to the child view model.
The problem comes when a view model that is very deep in the view hierachy needs dependencies that its parent controllers does not require. For example a service to access some external web service. Because its parent does not have that dependency it will have to add it to its dependecy list, thus adding a new parameter to the constructor. Imagine how this goes if the grand parent does not have the dependecy either.
What do you think is a good solution? Possible solutions:
Singletons: Harder to test and they are basically gloabl state
A factory class: We could a set of factory that knows how to create certain types of object. For example a ServiceFactory and RepositoryFactory. The service factory could have method to create services like: TwitterService, FacebookService, GithubService. The repository factory could know how to create a repository for each of the API resources. In the case of having a few factories (2 or 3) all the view models could dependent on this factories.
For now we have chosen the factory class solution because we don't need to use singletons and we can treat the factory as any other dependecy which makes it relatively easy to test. The problem is that it kind of feels like a good object and by having a factory you don't actually know which is the real dependecy that needs the view model, unless you look inside the constructor's implementation to check which factory methods are being called.
In our application, we have chosen to have our view models access their dependencies via dependency lookup rather than dependency injection. This means the view models are simply passed a container object which contains the necessary dependencies, and then "looks up" each dependency from this container object.
The major advantage of this is that all objects in the system can be declared up front in a container definition, and it is very simple to pass around the container, compared to the seventy-eight or so dependencies that might be needed.
As any dependency injection fan will tell you, dependency lookup is certainly its inferior cousin, largely because dependency lookup requires the object to understand the idea of a container (and therefore usually the framework that provides it), whereas dependency injection keeps the object blissfully unaware of where its dependencies came from. However, in this case I believe the tradeoff is worth it. Note that in our architecture, it's just the view models that make this tradeoff - all other objects such as your "models" and "services" still use DI.
It's also worth noting that many basic implementations of dependency lookup have the container as a singleton, but that does not have to be the case. In our application, we have multiple containers that simply "group" related dependencies together. This is particularly important if different objects have different lifecycles - some objects may live forever, while others may only need to live while a certain user activity is in progress. This is why the container is passed from view model to view model - different view models may have different containers. This also facilitates unit testing by allowing you to pass a container full of mock objects to the view model under test.
To provide some concreteness to an otherwise abstract answer, here's how one of our view models might look. We use the Swinject framework.
class SomeViewModel: NSObject {
private let fooModel: FooModel
private let barModel: BarModel
init(container: Container) {
fooModel = container.resolve(FooModel.self)!
barModel = container.resolve(BarModel.self)!
}
// variety of code here that uses fooModel and barModel
}
What you need to do is move the instantiation of all your objects to a Composition Root. Instead of parents passing down dependencies they don't even necessarily need to their children, you have a single point of entry at the start of your program where all of your object graph is created (and cleaned up, should you have Disposable dependencies).
You can find a good example here, by the author of the Dependency Injection in .NET book (highly recommended to understand concepts like the Composition Root) - notice how it frees you from having to pass dependencies 5 or 6 levels deep for no reason:
var queueDirectory =
new DirectoryInfo(#"..\..\..\BookingWebUI\Queue").CreateIfAbsent();
var singleSourceOfTruthDirectory =
new DirectoryInfo(#"..\..\..\BookingWebUI\SSoT").CreateIfAbsent();
var viewStoreDirectory =
new DirectoryInfo(#"..\..\..\BookingWebUI\ViewStore").CreateIfAbsent();
var extension = "txt";
var fileDateStore = new FileDateStore(
singleSourceOfTruthDirectory,
extension);
var quickenings = new IQuickening[]
{
new RequestReservationCommand.Quickening(),
new ReservationAcceptedEvent.Quickening(),
new ReservationRejectedEvent.Quickening(),
new CapacityReservedEvent.Quickening(),
new SoldOutEvent.Quickening()
};
var disposable = new CompositeDisposable();
var messageDispatcher = new Subject<object>();
disposable.Add(
messageDispatcher.Subscribe(
new Dispatcher<RequestReservationCommand>(
new CapacityGate(
new JsonCapacityRepository(
fileDateStore,
fileDateStore,
quickenings),
new JsonChannel<ReservationAcceptedEvent>(
new FileQueueWriter<ReservationAcceptedEvent>(
queueDirectory,
extension)),
new JsonChannel<ReservationRejectedEvent>(
new FileQueueWriter<ReservationRejectedEvent>(
queueDirectory,
extension)),
new JsonChannel<SoldOutEvent>(
new FileQueueWriter<SoldOutEvent>(
queueDirectory,
extension))))));
disposable.Add(
messageDispatcher.Subscribe(
new Dispatcher<SoldOutEvent>(
new MonthViewUpdater(
new FileMonthViewStore(
viewStoreDirectory,
extension)))));
var q = new QueueConsumer(
new FileQueue(
queueDirectory,
extension),
new JsonStreamObserver(
quickenings,
messageDispatcher));
RunUntilStopped(q);
Doing this is pretty much a prerequisite to do proper Dependency Injection, and it will allow you to very easily transition to use a container if you want to.
For the instantiation of objects that must be created after startup, or depend on data available long after startup, what you want to do is create Abstract Factories that know how to create these objects and take as constructor parameters all needed stable dependencies. These factories are injected as normal dependencies in the composition root, and are then called upon as needed with the variable/unstable arguments passed in as method parameters.
Here are a couple of suggestions.
Best coding practices suggests that if you are using more than 3 parameters, then you should use a class to host the parameters.
Another approach is to separate the data services [repositories] out, so that they line up to a task based service. Mainly to in line with the ViewModel (or Controller) So if you ViewModel uses Customers and Orders, most would use two services - one for CRUD operations on Customers, and one for CRUD operations on Orders. You could, however, use a service that will deal with all the operations needed for your ViewModel. This is a task based approach used in designing Windows Communication Foundation Services and Web Services.
It looks like you need to make use of the Managed Extensibility Framework (MEF), you can find more information here.
Essentially, what this will allow you to do is to use [Export] and [Import] attributes. This will allow your class' dependencies to be injected, without having to worry about massive constructors on your parent view models.
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'm updating a game from single player to multiplayer. In this case the game was originally written with most classes being single instanced. e.g. there was a single Player object, a single GameState object, etc. That is, each of these objects lived as long as the application.
Now that more than one player can play at once I obviously need to support creating more than one Player object, GameState object, etc. Over the course of working on this I have come to realize that most objects have one of three lifespans:
App's lifespan, e.g. a Conductor to handle navigation
Player's lifespan, e.g. the SettingsViewModel for the current player
Game's lifespan, e.g. the GameState for the current game
I'm curious how others deal with the creation of these different objects using an IoC container. I want to avoid creating factory classes for each class with a player or game lifespan.
Here is an example of IOC that may help. The project is called IOC-with-Ninject. It uses Ninject plus an IOC container class to manage all object life spans. You will need to do a little research on Ninject to customize it to your specific needs, but this is your IOC container solution (IMHO) if you are using .NET and will help you organize your code base. This is a personal choice, but I swear by it. If you are not using .NET it will still give you an easy pattern to follow. Cheers.
Many IoC containers have custom life-cycle scopes which you can manage as your wish. For example in Ninject you can define your custom life cycle scope as follows:
kernel.Bind<IService>().To<Service>().InScope((c, o) => yourCustomeScope);
As long as the yourCustomeScope variable has not changed, one single instance of the Service object is returned each time the kernel receives a request for IService. As soon as the yourCustomeScope variable changes, a new instance of Service will be created on the next request for IService. yourCustomeScope can be the current player instance, the game object or anything that you want to change the lifetime of the Service object, based on its reference change.
However, the objects that you just mentioned are more likely to be entities rather than services for which I don't think injection is a good idea.
From my experience the factories approach works the best.
Controlling lifespan of instance is clunky for support and requires efforts, knowledge of all of the classes lifespan requirements and dependencies, time for configuration and management of the configuration. In same time the use of factories is natural and code specific.
Factories (implementation) creation might be avoided by using proxy factories . You can also have factories returning generic arguments to further decrease the needs of factories (interfaces) creation.
If still too many factories are required I suggest reviewing the code flow.
I think this is in part a rehash of some of the comments of the previous answers but I have tried to exemplify expand a little on some of the reasoning.
Once you get into the domain of managing injected objects lifespan, you probably should be creating factories for these objects.
The underlying problem is that the composition root is not aware of what the environmental context of the call will be that needs to create the object.
I think I should take a step back and explain at this point.
Received wisdom on dependancy injection is to have a composition root some where near the entry point of the code. There are many good reasons for this that are not difficult to find on the web so I won't go into that here.
The composition root is where you map your interfaces (usually, but possibly objects) to their implmentations. You can pass in information that is available at this point to the constructor. So you can pass in a reference to an object whose lifetime is current at the time of execution of the composition root.
However, if the lifetime of the composition root does not overlap with the life time of the object you want to create you have to defer the execution of the constructor until the object needs to be created. This is why you need to have a factory. You can pass a factory method in to your mapping at this point and thus pass in the information needed to generate the object, but allow the creation to happen at the time it is required not when the composition root is executed.
You do not need a factory class to do this factory methods are fine, moreover the factory method can be inlined and so the code overhead is not much more than if we were creating the objects in the composition route.
If we have a project with 2 services where the first service is dependant on the first and we only want the lifetime of the second service to start when we create the first service we might have something like the following. (I am using ninject to give a code example, but I expect that other IOC containers work similarly in this respect.)
`
public class Service1:IService
{
private Func<IService>serviceFactoryMethod _Service2Factory;
public Service1(Func<IService>service2FactoryMethod)
{
_Service2Factory=service2FactoryMethod;
}
public void DoSomethingUsingService2()
{
var service2=_Service2Factory();
service2.DoSomething();
}
}
public class MainClass
{
public void CompositionRoot()
{
var kernel= new StandardKernel();
kernel.Bind.ToMethod(m=>
{
return new Service1(m.Kernel.Get<IService2>());
}
}
}
`
This example does not address how you would manage the lifetime of the App, players and games lifespans, but hopefully it gives sufficient clues as to how to remove lifetime issues related to dependancy injection.
Side note: that using Ninject you would be able to change the scope of Service2 in order to manage its lifetime to go beoynd the lifetime of Service1. For example, if you knew each instance of a game were to happen on its own thread (OK, this maybe somewhat unlikely), you might use InThreadScope for the game.
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.
Greetings,
Trying to sort through the best way to provide access to my Entity Manager while keeping the context open through the request to permit late loading. I am seeing a lot of examples like the following:
public class SomeController
{
MyEntities entities = new MyEntities();
}
The problem I see with this setup is that if you have a layer of business classes that you want to make calls into, you end up having to pass the manager as a parameter to these methods, like so:
public static GetEntity(MyEntities entityManager, int id)
{
return entityManager.Series.FirstOrDefault(s => s.SeriesId == id);
}
Obviously I am looking for a good, thread safe way, to provide the entityManager to the method without passing it. The way also needs to be unit testable, my previous attempts with putting it in Session did not work for unit tests.
I am actually looking for the recommended way of dealing with the Entity Framework in ASP .NET MVC for an enterprise level application.
Thanks in advance
Entity Framework v1.0 excels in Windows Forms applications where you can use the object context for as long as you like. In asp.net and mvc in particular it's a bit harder. My solution to this was to make the repositories or entity managers more like services that MVC could communicate with. I created a sort of generic all purpose base repository I could use whenever I felt like it and just stopped bothering too much about doing it right. I would try to avoid leaving the object context open for even a ms longer than is absolutely needed in a web application.
Have a look at EF4. I started using EF in production environment when that was in beta 0.75 or something similar and had no real issues with it except for it being "hard work" sometimes.
You might want to look at the Repository pattern (here's a write up of Repository with Linq to SQL).
The basic idea would be that instead of creating a static class, you instantiate a version of the Repository. You can pass in your EntityManager as a parameter to the class in the constructor -- or better yet, a factory that can create your EntityManager for the class so that it can do unit of work instantiation of the manager.
For MVC I use a base controller class. In this class you could create your entity manager factory and make it a property of the class so deriving classes have access to it. Allow it to be injected from a constructor but created with the proper default if the instance passed in is null. Whenever a controller method needs to create a repository, it can use this instance to pass into the Repository so that it can create the manager required.
In this way, you get rid of the static methods and allow mock instances to be used in your unit tests. By passing in a factory -- which ought to create instances that implement interfaces, btw -- you decouple your repository from the actual manager class.
Don't lazy load entities in the view. Don't make business layer calls in the view. Load all the entities the view will need up front in the controller, compute all the sums and averages the view will need up front in the controller, etc. After all, that's what the controller is for.