I read about VIPER architecture here http://www.objc.io/issue-13/viper.html (and in a few other sources), but I still can't figure out one thing, should each presenter interacts with at most one Interactor?
Here is a longer discussion about it that might better explain my question: Use Case with 2 ways for the same action
As I get it, the presenter is unique per VC. However, when a presenter needs several interactors, he may use them.
The interactors as for my opinion is a layer of business logic, they can interact with each other and the presenters can interact with many of them.
However, it's important to put the right logic in the right layer. For instance, be careful not to put the business logic in the presenter layer since its very tempting to while having to navigate between several interactors. Keep in mind to put the business logic only in the interactors.
Ideally, NO. One Presenter should know about the existance of only ONE Interactor. But the interactor itself can have many Data Managers. I usually use at least two data maangers: one for API requests and one for Local Data management.
For more advanced tips and helpful good practices on VIPER architecture, I recommend this post: https://www.ckl.io/blog/best-practices-viper-architecture (sample project included)
Ideally no, as Marcelo points out. However I feel like adding the "D" to VIPER for data managers is also not ideal.
A big problem in VIPER is that the presenter already knows which use case to "fire off" upon receiving input from the view, therefore it already has some apriori knowledge of the business use cases. This fact alone calls into question the entire architecture in my view, since if the presenter merely notified the interactor of a use-case-agnostic or purely UI event on the view, it would serve no purpose for existing. The presenter in VIPER has to have a tiny bit of "business logic", no matter what.
So, since the presenter already must orchestrate use cases by talking to the interactor, have one interactor per business use case, and the presenter can connect them if there is more than one business use case per "module". The boundaries in VIPER are often times difficult to maintain in practice without workarounds, but it is a nice architecture for forcing devs to think about separation of concerns.
According to the CheeseCake Best Pratices, the only what to connect multiple VIPER modules should be by using the Router Layer. This way, if you remove any module the only layer that will present errors in other related modules would be the Router. Also, to avoid coupling, Entities may be put in a separate module exclusive for this purpose. Finally, to mitigate the code duplication, similar entities (e.g., user and profile) would be grouped into the same data managers.
My opinion is: try to find out the trade-off between code replication and module decoupling. I'm refactoring just now my code and the code replication saved a lot of time when removing particular modules that were without any dependencies.
A little bit late to the party, but I just Googled this question searching for something else.
It really depends on your implementation of VIPER. There is no single correct one, from what I've seen people implement it in really different ways and it should be adjusted to fit your specific needs.
Some projects have tightly coupled interactor per view, where the view displays data, presenter passes the data between the view and interactor (converting it in the process) and the interactor handles the business logic per view. In this case the presenter would talk to only a single interactor.
Other projects implement interactors per use case, or in other words, "minor" feature. That way you can avoid duplicating business logic between the modules. The presenter can talk to multiple interactors here.
There are also projects that implement large interactor per "big" feature or should we say per area of the app. That way the interactors tend to be pretty large, but also really become the "smart" layer responsible for the business logic decision for the app and they tend to have access to everything they need to make those decisions.
Let's give an example here - let's say you have a log out button in the side menu of your app and also in the settings and that for the log out you need to clear your database, keychain, user defaults and the networking session. A rather common scenario.
In the first case, where you have and interactor per view, you'd obviously have duplicated business logic. I believe that's how the "original" VIPER works, but it's probably not the best approach.
In the second case you'd probably have a "user session interactor" handling just logging in and out the user.
In the third case, you'd have a "user interactor" that would not only handle the session, but also save and manage all the user's data.
My usual approach is the third option, with the big downside of the need to split the interactors over multiple files. Many people use the second option. It may also happen that for your project the first option is the best - for example if there is little overlap between screens in your project and they are tightly aligned with features.
Related
This is a somewhat open ended question about the UIViewController class, and their proper role in an iOS app.
I recently read this article, and I partially agree with the author. It's obviously important that every bit of logic related to your views and models doesn't end up getting dumped into the UIViewController, but it seems a bit extreme to build all of your views separately and use delegate methods to access the actions.
I'm curious about which design is most efficient in regards to the memory and performance of the app (clearly an important consideration when dealing with mobile apps)? As the author of the post pointed out, Apple doesn't seem to strongly advocate against putting logic in the UIViewController.
Ultimately, I'd like to know the right way of doing things. So the question is, should the views and any logic associated with it be completely separated out of the VC? Should I really be using delegates to communicate with the UIViewController?
A view controller is not evil by nature, although it's common for them to grow into monolithic messes because they are so convenient to extend.
…it seems a bit extreme to build all of your views separately and use delegate methods to access the actions.
Think of it as breaking up your program into smaller units, whatever that may be. Subclassing UIViews in every case isn't the best solution (as one example).
Each developer's tolerance is a bit different and it varies by program/case, but it's pretty easy to recognize and eliminate duplicate code, and to break your programs down into smaller units.
I think most classes:
should not exceed a few ivars (e.g. 2)
should not require more than 100 lines
should favor composition over inheritance. in many cases where you think you need inheritance, protocols may be used.
Of course, there will be exceptions.
I'm curious about which design is most efficient in regards to the memory and performance of the app (clearly an important consideration when dealing with mobile apps)?
It matters more that you will gain a lot by writing more reusable programs. Invest more time and effort into these reusable designs, reduce duplicate code, and focus on quality. Write performance and memory into your designs where it is a concern. Generally, this will result in a big win when compared to the dreaded freshly written, poorly tested, monolithic VCs.
Ultimately, I'd like to know the right way of doing things. So the question is, should the views and any logic associated with it be completely separated out of the VC? Should I really be using delegates to communicate with the UIViewController?
Oversimplification: No, you don't have to go that far if you eliminate redundant code, focus on reusability where applicable, and ensure your units/classes maintain low complexity. Absolutely, fix those problems before they grow into monolithic classes, regardless of whether they are VCs or another type.
I've also read this article a year ago, when I was looking for better iOS coding practices than what you see everywhere (dumping all kinds of crap in view controllers...). I agree with its points, although unfortunately it doesn't provide any kind of solution to the problem.
After a year of working on a fairly large iOS application, with complicated data model, remote services and highly nonlinear navigation, my experiences come down to these points:
Use view controllers for a single unit of user interaction, like prompting for login credentials etc. Basic validation (e.g. checking for empty fields, number formats etc.) takes place in the view controller, but if validation is part of your business logic, it should be put in your model.
I usually have a so-called controller object which orchestrates the UI flow, and connects it with the domain model. The controller receives user input from the view controllers via delegate mechanisms, so they're loosely coupled.
A single monolithic controller should be avoided; so I usually try to split my controller functionality between simpler, modular parts. For example, I have a controller which manages a registration process with a mostly linear UI flow, and its embedded in the main controller of the application so its
I'm building a MVC4 app, I've used EF5 model first, and kept it pretty simple. This isn't going to a huge application, there will only ever be 4 or 5 people on it at once and all users will be authenticated before being able to access any part of the application, it's very simply a place order - dispatcher sees order - dispatcher compeletes order sort of application.
Basically my question is do I need to be worrying about repositories and ViewModels if the size and scope of my application is so small. Any view that is strongly typed to a domain entity is using all of the properties within that entity. I'm using TryOrUpdateModel in my controllers and have read some things saying this can cause a lot of problems, but not a lot of information on exactly what those problems can be. I don't want to use an incredibly complicated pattern for a very simple app.
Hopefully I've given enough detail, if anyone wants to see my code just ask, I'm really at a roadblock here though, and could really use some advice from the community. Thanks so much!
ViewModels: Yes
I only see bad points when passing an EF Entities directly to a view:
You need to do manual whitelisting or blacklisting to prevent over-posting and mass assignment
It becomes very easy to accidentally lazy load extra data from your view, resulting in select N+1 problems
In my personal opinion, a model should closely resembly the information displayed on the view and in most cases (except for basic CRUD stuff), a view contains information from more than one Entity
Repositories: No
The Entity Framework DbContext already is an implementation of the Repository and Unit of Work patterns. If you want everything to be testable, just test against a separate database. If you want to make things loosely coupled, there are ways to do that with EF without using repositories too. To be honest, I really don't understand the popularity of custom repositories.
In my experience, the requirements on a software solution tend to evolve over time well beyond the initial requirement set.
By following architectural best practices now, you will be much better able to accommodate changes to the solution over its entire lifetime.
The Respository pattern and ViewModels are both powerful, and not very difficult or time consuming to implement. I would suggest using them even for small projects.
Yes, you still want to use a repository and view models. Both of these tools allow you to place code in one place instead of all over the place and will save you time. More than likely, it will save you copy paste errors too.
Moreover, having these tools in place will allow you to make expansions to the system easier in the future, instead of having to pour through all of the code which will have poor readability.
Separating your concerns will lead to less code overall, a more efficient system, and smaller controllers / code sections. View models and a repository are not heavily intrusive to implement. It is not like you are going to implement a controller factory or dependency injection.
In learning about Core Data, I've noticed how (in Xcode's templates) Apple directly used the query classes inside the view controller. This seems like it is bad MVC (having database access logic directly inside the view controller). Would it make sense to abstract out these kinds of actions to a separate suite of classes that obtain the data from the database and pass it back to the view controller calling it?
EDIT–
So, just to be clear, when I say "kinds of actions", I specifically mean CRUD Operations. Though if you have ideas about other things that a so-called "Model-Controller" would do, I'd be interested in hearing about them.
It's a matter of opinion, and often yes the templates are the most simple form of working example. It's hard to have a template spin out multiple files, for example.
Yes, personally, I generally spin out a separate NSManagedObject subclass. I like to have a _MySubclass object that has all the auto-generated stuff, then have the model actually reference MySubclass which has model-based business logic (you can use mogenerator or other methods to do this too if so inclined). Perhaps thinking of it as "Model-Controllers" and "View-Controllers" is another way of putting it.
This is a very good question and the answer likely depends on your situation. Perhaps architecture purists would insist on separate Model controllers and there are a lot of benefits to this approach. However, sometimes I find myself using Key Values when I'm doing a simple view. When things are more complex, for example, when coding the same Model for the Mac and iOS, having separate Model Controllers will allow you to reuse a lot of code. When you must diverge, Obj C Categories are a very clean way to extend functionality without adding a lot of overhead. I personally favor categories over extensive subclassing.
Since NSFetchedResultsController was released, my model classes are leaner. There are a lot of nuances to this and experience will help you come up with the best solution for your App. I've also found that writing unit tests up front will help you force through issues and validate your design, or send you back to the drawing board :)
Just curious why ManagedObjectContexts should be passed to UIViewControllers when they are created, rather than just grabbing them from a UIApplicationDelegate?
The docs say that this makes your applications more rigid, but I am failing to see the nuances of when to use which pattern.
Thanks!
Imagine that I ask you to do some task, like painting a room. If I just tell you "go paint a room," you'll need to ask me a lot of questions, like:
Which room?
Where's the paint?
Where are the brushes?
Should I use a dropcloth?
In short, you won't be able to complete the task without help from me. If you have to depend on me every time, you won't be a very flexible painter. One way to deal with that problem is for me to give you all the stuff you need at the outset. Instead of "go paint a room," I'll say "please paint room number 348 using this bucket of paint and this brush, and don't bother with a dropcloth." Now, you've got everything you need, and you can get right to work with no further help from me. You're a much more flexible worker because you no longer depend on me.
The same thing applies to view controllers (and objects generally); it's better to give them everything they need than to have them depend on a particular object like the app delegate. It's true not just for managed object contexts, but for any information they need to do their job.
This is mainly because you want to use dependency injection with your UIViewControllers instead of just grabbing everything from UIApplication, this keeps your delegate clean instead of full of reference hacks.
This is also to keep with the MVC pattern:
Model
View Controller (Only for view logic)
Controller (For coordinating between the view and the model)
I tend not to agree with this pattern.
First of all I try to treat Core Data as an implementation detail, and as any implementation detail it should be hidden behind a good facade. The facade is the interfaces I expose for my model objects. For example if I have two model objects; Cource and Student, any cource can have a number of students. I do not want to let the controller take upon the duty to setup predicates and sort descriptors, and jump through all Core Data hoops just to get a list of students for a particular class. There is a perfectly valid way to expose this in the model:
#interface Cource (StudentAccess)
-(NSArray*)studentsStortedByName;
#end
Then implement the ugly stuff once and for all in the Model class. Hiding all the complex details of Core Data, and no need to pass around managed object contexts. But how would I find the sources, it has to start somewhere right? Yes, it does but you need not expose it to the controller. Adding methods such as these are perfectly reasonable as well:
#interface Cource (CourceAccess)
+(Cource*)caurceByID:(NSString*)courceID;
+(NSArray*)allCources;
+(NSArray*)courcesHeldByTeacher:(Teacher*)teacher;
#end
This also helps in minimizing dependencies between controllers. And reducing he dependencies between the model and controller. Assuming I have a CourceViewController and a StudenViewController is I did not hide the Core Data details behind a facade and wanted to pass around the managed object context as well, then I would end up with a designated initializer like this:
-(id)initWithManagedObjectContext:(NSManagedObjectContext*)moc
student:(Student*)student;
Whereas with good a good facade I end up with this:
-(id)initWithStudent:(Student*)student;
Minimizing dependencies behind facades, in favor of dependency injection also makes it much easier to change the internal implementations. Passing around the managed object context encourages each controller to implement their own logic for basic stuff. Take for example studentsSortedByName method. At first it might be sorter by last/first name, if later changed to last/first name sort you would have to go to each and every controller that has sorted students and make the change. Where a good facade method requires you to change in one method, and all controller automagically get the update for free.
The Apple Docs try to foster the most widely applicable and sustainable design patterns.
Dependency injection is preferred because it allows for the most flexible, expandable, reusable and maintainable design.
As apps grow in complexity, using a quasi-singleton like parking the context in the app delegate breaks down. In more complex apps, you may have multiple context tied to multiple stores. You might want the same view-controller/view pair to display data from different context at different times or you may end up with multiple context on different threads/operations. You can't pile all those context up in the app delegate.
If you have a simple app with a single context then using the quasi-singleton with the app delegate can work well. I've used it on several smaller apps in the past without immediate issue but I did hit scalability problems on a couple of apps when the apps grew overtime.
Which pattern to use depends on your shipping constraints and you best guesses about of the evolution app over its entire lifecycle. If its a small one shot app, then the app delegate quasi-singleton will work fine. If the app is more complex, might grow more complex or might spawn other related apps that will reuse existing components, then dependency injection is the way to go.
At my company we're about to build a new site using ASP.NET MVC. My boss (marketing guy) would like to know some more about the technology so I've tried to find a really good, simple and pedagogical presentation of the MVC concept without any luck. Most of them require quite a lot of basic knowledge in programming.
Any suggestions for a good video, slides or other?
Craig Strong has a pretty nice article about MVC in general and how to explain its benefits to business. Check it out here: Updated link.
Define MVC in layman’s terms
Remember you’re technically minded and close to the code. MVC to you
is as clear as day, but saying to the business ‘Model, View,
Contoller’ could give them the impression that you are suffering from
some form tourette syndrome. MVC won’t mean much to the business even
after you define them in relation to the code. To get the business to
understand why this is the answer and least of all what it is, can be
more of a task than expected in my experience. Even some fellow
developers have difficulty understanding this on occasion.
To get the listener to understand what MVC is and why it works what I
have tried in the pass is to apply MVC to a different industries where
the listeners have had more involvement. An example that has worked
for me in the past in a comparison to the property or even the
vehicles. Most people have had dealing’s with builders, carpenters,
plumbers, electricians or have watched the flood of property shows on
the TV. This experience is a good platform to use and to explain why
separation such as MVC works. I know you’re probably thinking that
won’t work as it’s not the same as in software, but remember you’re
not trying to train the business to become developers or have an in
depth understanding of MVC, simply explaining to them that separation
in production is required and that’s what an MVC structure offers.
To give an example of how you could describe this I have very briefly
explained how separation works in property. Keep in mind this is
focused on using the system not developing which could be a completely
different angle of explanation.
View
The view in MVC is the presentation layer. This is what the end user
of a product will see and interact with. A system can have multiple
views of all different types ranging from command line output to
rendered HTML. The view doesn’t consist of business logic in most
clear designs. The interface is fit for purpose and is the area of
interaction. Therefore you could simply output HTML for consumers to
interact with or output SOAP/XML for businesses to interact with. Both
use the same business logic behind the system otherwise known as the
models and controllers.
In the world of property you could think of the view as the interior
of a property or the outer layer of a property that the inhabitants
interact with. The interior can be customised for purpose and the same
property can have many different types of tenants. For example a
property of a particular design could contain residential dwellings.
The same internal space could easily be used as office space, where
although in the same property has a different purpose. However the
property structure is the same. Therefore the environment in which the
users interact does not interfere with the structure of the building.
Controllers
The controller is where the magic happens and defines the business
application logic. This could be where the user has sent a response
from the view, then this response is used to process the internal
workings of the request and processes the response back to the user.
Taking a typical response where a user has requested to buy a book.
The controller has the user id, payment details, shipping address and
item choice. These elements are then processed through the business
logic to complete a purchase. The data is passed through the system
into the model layer and eventually after the entire request satisfies
the business definitions, the order is constructed and the user
receives their item.
If we compare this to a property, we could compare the ordering of a
book online to turning on a light switch. A tenant will flick the
switch to on just like ordering a book. The switch itself is an
element in the view layer which sends the request to the controller
just like clicking a checkout button on a web site. The business logic
in this case is what the electrician installed and are embedded within
the property designs. The switch is flicked, which completes the
circuit. Electricity runs through all the wires including the fuse box
straight through to the light bulb. Just like the user receiving a
book, in this case the tenant receives light. The whole process behind
the scenes involving the electricity cabling is not visible to the the
tenant. They simply interact with the switch within the space and from
there the controller handles the request.
Models
The models in MVC are the bottom most layer and handle the core logic
of the system. In most cases this could be seen as the layer that
interacts with the data source. In systems using MVC, the controller
will pass information to the model in order to store and retrieve
data. Following on from the example above controller definition, this
is where the order details are stored. Additional data such as stock
levels, physical location of product of the book amongst many things
are all stored here. If that was the last book in stock ordered, the
next request for this item may check if it’s available and disallow
the order as the item is no longer available.
Sticking with our example of turning on a light switch, this level in
our structure could be the electricity supply. When the tenant flicks
the switch, the internal circuit must request electricity to power the
request which is similar when the user requested data from the
database, as in data is needed to process a request. If the dwelling
isn’t connected to an electric supply, it cannot complete the process.
Business benefits from using MVC
After you get the message across explaining what MVC is, you will then
have to see what benefits can be obtained from it. I’m not going to go
into a huge amount of detail here are I’m sure you can apply benefits
more accurately which are directly related to you actual situation. To
list just some of the common benefits of an MVC based system here are
a few examples:
Different skill levels can work on different system levels. For example designers can work on the interface (View) with very little
development knowledge and developers can work on the business logic
(Controller) with very little concern for the design level. Then they
simply integrate together on completion.
As a result of the above separation projects can be managed easier and quicker. The designer can start the interfaces before the
developer and vice versa. This development process can be parallel as
opposed to being sequential therefore reducing development time.
Easy to have multiple view types using the same business logic.
Clear route through the system. You clearly know where there different levels of the system are. With a clear route of the system,
logic can be shared and improved. This has added security benefits as
you clearly know the permitted route from the data to the user and can
have clear security checks along the route.
Each layer is responsible for itself. (Relates to point 1) This means that you can have clean file structure which can be maintained
and managed much easier and quicker than a tightly couple system where
you may have lots of duplicate logic.
Having a clear structure means development will be more transparent which should result in reduced development time,
maintenance problems and release cycles if applied properly.
M-V-C Think of it as:
"Order Details (including Customer & Employee info)", "HTML/ASP Form (to display the OrderDetails)" and "Order details service class (having methods to SaveOrderDetails, GetOrderDetails etc.).
The Model (Data Class e.g. OrderDetails)
The data you want to Display
The Controller (Service class)
Knows about the Model (Order Details)
Has methods to manage the Model
And as such can be unit tested Its Single Responsibility is to manage the OrderDetails CRUD operations.
It knows NOTHING about the View
The View (ASP Page)
Displays the Model (OrderDetail's ViewData).
It has to know about the Model's structure so it can correctly display the data to the users on screen.
The View's structure (style, layout, HTML etc., locale) can be changed at anytime without it changing anything in the application's functionality.
And as such, many Views can display the same Model in many different ways.
In multi-tenant web applications, Customer specific Views can be stored in a database table and displayed based on Customer information
You have to explain the benefits of ASP.NET MVC, not the features
You have control over your URLs -- that means SEO for the site will be better -- that means your site will be higher in google
The code is cleaner, which means that it's easier to change, which means that you can add features faster
etc.
How do you save money, make money, reduce risk? That's what your boss wants to know.
Imagine a control room in a factory, the model is the machine itself, the monitoring equipment is the view and the instrument panel is the controller. You could have several different control rooms for the same machine and changes in the controls in one control room would reflect on the monitors in all control rooms.
The point is that you should only model once and then view or control however is most convenient.
The model is the data access layer, which can just be a wrapper for a few simple queries to an ORM that manages the data entity relationships itself. It handles communication to the data source, retrieves data and usually organizes it into objects defined in your application.
The views are just html files with bits of html and css with some templating engine (smarty, mako, etc) code to display the data passed to it the way you want.
The controller puts it all together. Requests made to your page will be routed to a controller (class) and an action (method) within the controller. Just like any other application, the action will do what's requested of it, but it's still part of the controller.
So, the controller uses the model to query data (users, content, etc), then passes the data to a view to be rendered and displayed the way you want.
I wouldn't try to explain the technology to him, I'd try to explain what the MVC architectural principle is all about.
MVC was designed to separate concerns. Plain and simple. Explain to him that when you build anything that what you're building can be classified in two different categories: what the business need is (the domain), and everything else.
MVC separates the Domain from the everything else by introducing layers to separate out the concerns. M is for Model, which is your domain. V is for View, which is the visible part to him, what he sees. C is for Controller, the part that controls what is going on in between the Domain and the View.
The marketing guy would just be interested in the "V" part, the View. Depending on how you design things, the View would just be basic HTML/CSS "templates" that the marketing person could modify. Technically without breaking anything.
Ideally the Model (database) and Controller (logic) shouldn't care if the View (presentation) is XML, HTML, text, etc. The marketing person shouldn't care what the Model and Controller do, except for requesting additional functionality.
Going further with the "ideal", you should technically be able to replace ASP with PHP, Java, Ruby, etc as the Controller without touching the Model or View.
You can very easily do this, that is if you understand marking speak. I dont but I imagine it would go something like this...
This should be use. MVC (if done right) will allow you to decouple the UI from the data (model) and control of the UI (controler). This will allow the UI to be more flexible which will in turn allow to better market it self faster.
To a marketing guy, perhaps the best way to explain the reason for ASP.Net MVC is the ability to broaden your product's reach.
By using MVC, the code is already separated in a fashion that will let you more easily build an interface that feels natural on a desktop, and then the different interface that caters to a general mobile device user, and a still-slightly-different interface that caters to an iPhone user, without risking the backend code getting out of sync and introducing subtle and company-harming bugs. And, if there's a smart client desktop app that could be a product... it, too, can rest on the same codebase.
The Model is "how things work inside the box". The Controller is "what you can touch on the outside of the box" and the view is "what comes out of the box"...
The most important thing for your marketing guy is money, budget, TCO ...
When you don't use MVC you usually mix design, application logic etc. alltogether.
Programmer then must know html design, programming etc... That could mean you need powerful professional to do it all.
if you use MVC, everything is divided into "separate parts". Html coder can prepare html layer, programmer only works with application logic etc...
MVC brings better granularity and everybody can focus on what he or she can do the best!
Listen, for example xhtml validity and css cleanliness is so hard that there is a lot of people who focuses only on this while lot of browsers and platforms compatibility on mind.
Usually one person is NOT the best asp.net programmer, xhtml coder in one ;-)
This is a pretty simple one
http://en.wikipedia.org/wiki/Model-view-controller#Pattern_description
The best way I can thing of is that the model is the data representation, the view is the presentation to the user and the controller is what collects user interaction that changes the model.
The important word in the title of the manager in this case is "marketing." He is a Marketing manager. The concerns one has as a marketing manager have to do with strategy and tactics. These two are not the same thing. Strategy is the big picture word that embraces among other things how a company conceptually addresses customer needs and how the company differentiates itself from its competition. Strategy is typically not what software can portray to a user. Tactics, on the other hand, are the direct methods or approaches that a company takes in winning the business of the customer. Tactics tend to change far more frequently than strategies, and it is likely that the marketing manager, when he asks what advantage MVC may give him, is really asking, "How rapidly can you change whatever it is that you create into something that conforms to new realities in the way we have to deal with customers." In other words, how quickly can you change an offer of "buy 1 and get 1 free" into "buy 2 on Friday and get 1 on the following Tuesday if it is raining in Albany."
Marketing management is about results measured in dollars and cents, not finery and nuanced explanations that are littered with conceptual words lacking any real specificity. Everything a programmer may say might make sense to himself, but a marketing manager needs to know the real likelihood of rapid response to changing customer perceptions or rapid implementation to a different approach to selling to the same customers. He needs to know if it will cost more than an existing method because if he sells $1 million more in product while spending $1.25 million in software development, he will probably lose his job.
So, in short, he is looking for flexibility and cost-effectiveness. He needs software that be adapted to changing conditions quickly, just as he changes his pitch first one way and then another to a difficult-to-persuade prospective customer, and he needs to know that he won't have to be liable for a huge price tag for that flexibility.
Frankly, I don't think that you would be able to deliver on such promises if they were made because in spite of all the advantages of MVC from a development point of view, we are still talking about software here, and as we all know, software is a rigid, demanding taskmaster that takes it own sweet time to mature to the point of trustworthiness and to be rid of its bugs. We as programmers are always in search of the holy grail of software reusability, and while we flail about trying one thing and then another (MVC, MVP, MVVM, and whatever else someone may conceive), the rest of the world is simply asking for something that works. So the best of luck to you. I hope you are able to win your case.