I am new to iOS development, so please excuse me in case my question sounds trivial.
I am planning to introduce MVP or VIPER pattern. I am from Web background and in web application we used to follow different layers/dlls (for model, view, common etc.). Does it make sense to follow the same layered approach (frameworks in this case) in iOS and or it will be overkill? I have not come across any sample project (based on MVP) which create different framework for model, View and Presenters? It would be great if someone can share any sample project (based on MVP) which we can use as a starter project.
Thanks In Advance
In iOS, we generally use MVC - Model/View/Controller. So, if you're looking for the analog in the iOS world, that's it. If you're saying that you've really dug into MVC and there's something that you find deeply unsatisfying, and therefore want to introduce a different pattern, then that's a different question.
So, no, the sort of logical separation of responsibilities that you see in approaches like MVC is not overkill. In fact, the division of "view" and "controller" classes are fairly central to everything we do (e.g. UIView subclasses, UIViewController subclasses, etc.), so the only thing you really have to do is design appropriate "model" classes and you're off to the races.
But, in answer to your question, you don't generally use separate framework targets for the model, the views, and the controllers. That probably would be overkill. Usually you can keep track of everything through through judicious use of Xcode groups/folders within your project. We generally only pull stuff into frameworks for more technical or logistical reasons (live views, app extensions, sharing code between multiple apps, etc. ... see WWDC 2015 Building Modern Frameworks for discussions of when you'd generally use frameworks).
But to the question of MVC vs MVP or VIPER (or MVVM or whatever). I'd suggest that you simply embrace the shared spirit of all of these patterns (namely the separation of responsibilities) and apply it to your iOS MVC code. Once you've got some iOS experience under your belt, you can then re-evaluate this pattern question.
If you're starting with iOS developement and is looking for a good architecture, go with VIPER. It's not at all an overkill as long as you:
1 - Automate VIPER files generation
2 - Automate VIPER modules initialization
To accomplish both requirements above, use this Xcode plugin (https://github.com/natangr/ViperTemplate) to generate and intialize VIPER files automatically. It works like charm!
And read this post https://www.ckl.io/blog/best-practices-viper-architecture to get more tips on how to automate things when using VIPER.
I do use it, even for very small projects (160h of development)
Related
Can anybody explain the real scenario for implementation of MVC vs MVVM vs VIPER for iOS based project.I'm looking some example which explain that where we should use MVC,MVVM and VIPER.
Thanks in advance.
https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52#.58u55ykux
There is no silver bullet so choosing architecture pattern is a matter of weighting tradeoffs in your particular situation.
I agree, there is no right or wrong way to do it. We have been using a VIPER/Clean architecture inspired architecture on a medium sized project (~70k lines of code) at my former company. It made sense for us to go with this approach because we have had quite a lot of business logic that should not change that often. Additionally, the architecture communicates intent so it is easier to understand what your application does (your use cases) instead of which frameworks and technologies you use.
If you want to know more about clean architecture inspired architectures such as VIPER, I suggest you have a look at Uncle Bob's talk on youtube.
https://www.youtube.com/watch?v=Nsjsiz2A9mg
If you are unsure which direction to go: follow the single responsibility principle (which you might want to follow anyway). That way you can recompose the parts later on to achieve the architecture style you've settled on.
Assume a web project by ASP.NET MVC 5 and OWIN/Identity membership. The IoC is done with Unity. Everything is within one project now.
Question: Does it make any sense to separate MVC, Idenity and IoC to isolated projects and encapsulate Identity into some IAccountService to be resolved by Unity in MVC project?
The question seems to be quite silly, but my rubber duck keeps silence for unknown reasons, any guess?
The goal I want to achieve looks like this
ASP.NET MVC (OWIN) --> IoC (Unity) --> AccountServiceImpl --> Identity
Both MVC, IoC --> Contracts (IAccountService)
where --> is a project reference
I need it to be able to change IoC container and also I need Identity data to be accessed from another projects through an interface
Yes, it is safe to separate your solution into smaller projects such as MVC, Identity and IoC.
At least, that's my short answer.
Does it make sense? The long answer is a little bit more complicated. I've answered some similar questions before where I address solution and project architecture:
where should the interfaces be defined?
Where should I put automapper code?
In the answer above, I explained
[...] I have a typical structure like this:
MyProject.Core
MyProject.Domain
MyProject.DependencyInjection
MyProject.Infrastructure
MyProject.Web
MyProject.Tests
Jeffrey Palermo encourages the use of Onion Architecture. In part 4 of his article on Onion Architecture, Jeffrey provides an example solution with the following structure
Core
Infrastructure
IntegrationTests
UI
UnitTests
However, Jimmy Bogard somewhat disagrees with me and my approach.
In Evolutionary Project Structure, Jimmy explains:
I used to care quite a bit about project structure in applications. Trying to enforce logical layering through physical projects, I would start off a project by defaulting to building an app with at least two projects, if not more.
Indeed, Jimmy describes his previously-preferred solution architecture style as being similar to the style that I've mentioned above.
Jimmy goes further to say that "deciding about project structure is a waste of time and energy". He actually prefers a simpler solution structure. That is, very little.
Although Jimmy does clarify his position by saying:
I have absolutely nothing against layered software design. Using project structure to do so is a waste of time if you only have 1 app you're deploying [...]
(Emphasis mine)
If you have other applications needing to reference aspects of your MVC solution, it may very well make sense to split them out into their own projects so that you can easily reference them.
I think what we should conclude is that:
Solution architecture isn't a rule or a law. Separate projects out where it makes sense.
Make sure your solution is easy to maintain and easily understood by others. Don't over-complicate your solution.
I'll add my 0.02ยข to the excellent answer from Rowan. I'll say more about actual Identity implementation.
As far as ASP.Net Identity framework goes - it might be slightly tricky to move it out of MVC project into higher (or lower, depends how you place it) sitting layer. I'm pretty sure you'd want to have ApplicationUser object in your domain layer. But ApplicationUser depends on IdentityUser which depends on Identity.EntityFramework, depending on EntityFramework. And adding EF to your domain project might go slightly against the rules of Onion Architecture.
Also ApplicationUserManager from Identity framework is massive (in terms of number of methods) and also depends on EF. So hiding it behind an interface can be tricky.
So really you have 2 options:
Take a hit and add EF into your domain project and have ApplicationUser and ApplicationUserManager classes in your Domain layer. And don't wrap UserManager in an interface for multiple reasons.
Take a hit in different way and leave all Identity stuff in your MVC layer, identify very small set of actions that you need to execute from Domain layer and add a tiny interface on top of ApplicationUserManager.
I have tried both and both approaches in different projects and both work equally well. I have tried adding interface on top of ApplicationUserManager and failed - mostly because of the size of the class, also it is aimed to work in async manner and there are sync-wrappers. Sync wrappers will not work with your interface - because strong-typing.
I've written a blog-post about applying DI to Identity framework and there is a discussion in the comments about layers separating - have a look for ideas.
I've been seeing a lot of articles and references about how to use this patterns for my first (please keep this in mind) serious project with ASP.NET MVC 3 and EF.
The project is not so big (13 tables) and it's basically a CRUD maintenance: organisations that have some users; users that can belong to a group and can create some work areas and templates... Nothing complicated. The point is that this will be the first of a project series and I'd like to create a base to work with.
My questions are:
Which of the previous patterns is the best? Does it depend of the project size?
My models would be these:
Unit of work
Dependency Injection
Do you think they are good enough and appropriate for my project?
I appreciate all your comments.
Serious application doesn't mean to be complex at first sight.
Over engineering an application upfront can be a real disaster, especially if you don't grasp all the technologies involved.
My advice would be to keep it simple. Create a basic application that fulfill requirements (get the thing done and make your boss happy) and then add new concepts along your learning path.
That doesn't mean I promote bad code, no way! Keep your code clean, well organized, etc. But don't be killed by the fear of doing something wrong.
It's normal for a developer to look back to an application made a few weeks ago and then realize that he did some shitty stuff. That's how we progress!
Last but not least, have FUN!
ASP.NET website provides usefull resources to learn the framework and all related guidances. There are a few application samples created step-by-step.
ASP.NET MVC was built with Dependency Injection in mind.
If you want to give a chance to your code to be loosely coupled and easier to change in the future you have to follow the patterns like Dependency Injection, Repository (for presistance abstraction), and UoW (for transaction abstraction).
So my answer is, you should learn about them in the first place to decide after if you want or no to follow the best practices. Even for simple project it's good to apply these patterns because often it gets bigger and bigger. and it's easy to do it in MVC so why to avoid it ?
There is many resources around to learn about. You can just google it.
I would like to answer this question in more generic way. Creating something which can be used in future is difficult than what it seems. All the pattern above can provide you infrastructure pieces to come up with some base framework.
But I would strongly suggest you to look at S.O.L.I.D principals (DI being part of it) to understand some qualities of good code. These are applicable irrespective of the technology involved.
You cannot predict the future requirement of a product\framework, but following these principle you can be better prepare to handle any future modification to the software
You might want to check out S#arp Lite which has many good examples of how to implement the things you want and can serve as a very good base on which to build something quickly.
None of the mentioned patterns are mutually exclusive. You should use the patterns that make sense based on what you are trying to accomplish, not attempt to shoehorn your application design into someone elses idea of how it should work. Sometimes trying to bend your scenario to fit a particular design pattern / practice is the worst thing you can do.
Want to make sure good unit test coverage / do TDD / ensure loose coupling? Then Dependency injection is your friend, as is the Unit of Work pattern. This is definitely a good idea for creating a maintainable, scalable application, but you can go too far with it for a small-scale application.
Need a centralized caching strategy for your data source? Then use the repository pattern. Or an ORM like NHibernate, which might do it for you.
I am a total beginner in iOS development. However, I've done Java, PHP and Javascript at work for severals years, so I am pretty experienced with OOP and design patterns.
Xcode 4.2 adds the new storyboarding capability for laying out interfaces in iOS 5.0. Is storyboarding simply a wizard for beginner developers or does it have advantages for more experienced developers as well?
My coworkers and I (both beginners in iOS development) are debating whether one should learn and program iOS using traditional NIBs vs storyboards. What are the advantages that storyboarding provides over previous ways of laying out iOS interfaces? Are there disadvantages to this approach?
Learn the old way in case you have to do both (or read some legacy code). This goes for Arc too; I shudder to think of new Cocoa/Cocoa Touch developers not understanding the old managed memory model.
I think the automated and convenience methods will always cover the "common" cases, and that story-boarding is an example of that. A convenience which greatly simplifies and accelerates the development process. However, there will always be cases where these methods do not provide you with all you need in a given, unusual situation. Just like using the UI elements does not stop developers from going under the hood with core graphics, core audio and so on when they need to. It is definitely, I think, a part of the future of iOS development, but only being aware of that part would be a handicap. So would not being aware of it.
I, personally, dislike automated tools. I have no idea what happens below, what sort of surplus code is inserted, the style of code is not mine and hence I need to work on another person's code. I'm the one that needs to support it for rest of time, not whatever automated tool I may have used.
It is all the tedious abstractions that will help you understand what is going on, especially when you are new to a field.
I'm personally like the traditional nib file approach, where I have more control over its behavior programatically and not having to hack the stroyboard backward to get things done. And of cause, if you have few developer working in a project, it's always good that you don't have to spend time merging changes (since you have several nib file compare to storyboard file)
storyboard files seem to be more readable than xibs.
both are xml files but the xibs seem to have unnecessary baggage and complexity.
I have compiled a list of about 15 reasons against using Storyboards: When to use Storyboard and when to use XIBs
Also, here's a tool that takes some of the pain away: http://github.com/jfahrenkrug/StoryboardLint
Most web frameworks are still using the traditional action based MVC model. A controller recieves the request, calls the model and delegates rendering to a template. That is what Rails, Grails, Struts, Spring MVC ... are doing.
The other category, the component based frameworks like Wicket, Tapestry, JSF, or ASP.Net Web Forms have become more popular over the last years, but my perception is that the traditional action based approach is far more popular. And even ASP .Net Web Forms has become a sibling name ASP .Net Web MVC. Edit: Maybe my perception was wrong because of the impression of increasing interest in Wicket. If I ask Google Trends, there is much more growth in the tradional MVC frameworks.
I think the kind of applications built with both types of frameworks is overlapping very much, so the question is: Why are action based frameworks so predominant?
the component based frameworks like
Wicket, Tapestry, JSF, or ASP.Net Web
Forms have become more popular over
the last years
[Citation Needed]?
I seriously doubt this claim. MVC has taken over the .Net blog/twitter sphere. Its really hard to find somebody saying "we'll use webforms for our next project".
MVC fits the stateless nature of the web better. Component frameworks are an abstraction web developers didn't want.
Why are things more popular? They are several reasons: because of a good user experience, fast development cycle, cheapest things, etc
But sometimes
the loudest
or most hyped (rails, although it is great ;-))
or most arrogant (apple)
or the things with the most aggressive marketing (microsoft)
will win.
That is called evolution.
BTW: I am with Thevs. The component based frameworks will be the final winners (like GWT/Vaadin or wicket).
Inertia. Once you've invested a lot in one technology, it becomes progressively more difficult to change to something better. And it is not 10 times better, because then everyone (even the CEO) would have seen the change is needed.
I believe it's because action-based frameworks give developers (and designers) more control over the appearance of the page. Component-based frameworks try (unsuccessfully, IMHO) to hide the fact that the web is the web. They try to make web programming something like programming a native desktop widget toolkit like WinForms or Cocoa.
But the web is very, very different from that. I think action-based frameworks are popular because they recognize this.
EDIT
Apparently some people have misunderstood what I mean by this, so let me be clear. I'm NOT criticizing web application that appears to users to function like a desktop application. I have absolutely no problem with that.
What I'm talking about is the underlying coding methodology and philosophy. Each tag in a tag library system renders HTML in a certain way, analogous to a widget in a desktop programming library like Cocoa or WinForms. Some systems allow you to customize the rendered HTML, but this can sometimes be non-trivial to accomplish. It will render CSS classes and so on over which you either have little control or have to make a special effort to control. It pretends to be a black-box solution, but it cannot possibly be, because if you want to style the rendered HTML or target it with JavaScript, you have to understand its structure and so on.
I suspect that developers are using MVC frameworks as a simple way of exposing services, not as action-based web app frameworks (this is pure speculation on my part). i.e. they are using them for AJAX requests. I would predict that the concept of action-based frameworks quietly goes away over the next couple of years, along with (to some extent) the concept of MVC in this context.
I think you only see these frameworks showing all around. But most programmers use in-house (custom) or much more simple framework models (like ExtJS or JQuery) and silently do their job.
EDIT: By the way, I think MVC model is trying to mimc the old and probably obsolete business/presentation separation model which was proposed for legacy applications some time ago.
I see no future for this model (2-3 years from now). AJAX is already changing all the way you're working with backend.