We currently have a home grown authz system in production that uses opa/rego policy engine as core for decision making(close to what netflix done). We been looking at Zanzibar rebac model to replace our opa/policy based decision engine, and AuthZed got our attention. Further looking at AuthZed, we like the idea of defining a schema of "resource + subject" types and their relations (like OOP model). We like the simplicity of using a social-graph between resource & subject to answer questions. But the more we dig-in and think about real usage patterns, we get more questions and missing clarity in some aspects. I put down those thoughts below, hope it's not confusing...
[Doubts/Questions]
[tuple-data] resource data/metadata must be continuously added into the authz-system in the form of tuple data.
e.g. doc{org,owner} must be added as tuple to populate the relation in the decision-graph. assume, i'm a CMS system, am i expected to insert(or update) the authz-engine(tuple) for for every single doc created in my cms system for lifetime?.
resource-owning applications are kept in hook(responsible) for continuous keep-it-current updates.
how about old/stale relation-data(tuples) - authz-engine don't know they are stale or not...app's burnded to tidy it?.
[check-api] - autzh check is answered by graph walking mechanism - [resource--to-->subject] traverse path.
these is no dynamic mixture/nature in decision making - like rego-rule-script to decide based on json payload.
how to do dynamic decision based on json payload?
You're correct about the application being responsible for the authorization data it "owns". If you intend to have a unique role/relationship for each document in your system, then you do need to write/delete those relationships as the referenced resources (or the roles on them, more likely) change, but if you are using an RBAC-like design for your schema, you'd have to apply these role changes anyway; you'd just apply them to SpiceDB, instead of to your database. Likewise, if you have a relationship between say, a document and its parent organization, you do have to write/delete those as well, but that should only occur when the document is created or deleted.
In practice, unless you intend to keep the relationships in both your database and in SpiceDB (which some users do), you'll generally only have to write them to one or the other. If you do intend to apply them to both, you can either just perform the updates to both at the same time, or use an outbox-like pattern to synchronize behind the scenes.
Having to be proactive in your applications about storing data in a centralized system is necessary for data consistency. The alternative is federated systems that reach into other services. Federated systems come with the trade-offs of being eventually consistent and can also suffer from priority inversion. I presented on the centralized vs federate trade-offs in a bit of depth and other design aspects of authorization systems in my presentation on the cloud native authorization landscape.
Caveats are a new feature in SpiceDB that enable dynamic policy to be enforced on the relationship graph. Caveats are defined using Google's Common Expression Language, which a language used for policy in other cloud-native projects like Kubernetes. You can also use caveats to make relationships that eventually expire, if you want to take some of book-keeping out of your app code.
This question might be asked a thousand of times but a lot of confusions and contradictions in the answers.
I ask about the validations in the context of domain driven design.
In which layer should the validations be done mainly ?
Is it acceptable for the object to be in invalid state? because many answers said that it's okay and mainly because of historical data and the business rules may change over time and loading historical data might cause problems?
Many implementations consider throwing exceptions in the domain layer and mapping the messages to the UI although Martin Fowler recommends to Replacing Throwing Exceptions with Notification in Validations! When to return messages and when to throw exceptions in the validation context ?
Many articles explain some tips or paths to follow like Vladimir Khorikov and jbogard in their articles but in the comments they confess that they do things a wee differently now. Are these patterns still valid?
Should I use framework like FluentValidation and if I use it, Is this frame work used only in the application layer as an alternative to the MVC annotations ?
When Should I use Business Rule Framework (BRF) instead?
I know many questions here but they target the same spot(Validation in DDD).
Note: I don't use CQRS pattern because it made the application so complex.
So I have (domain layer,data layer, application layer(MVC), and shared kernel)
In which layer should the validations be done mainly ?
Mainly in Domain, except for infrastructure related validation, e.g. xsd validation or json schema for instance.
Is it acceptable for the object to be in invalid state? because many
answers said that it's okay and mainly because of historical data and
the business rules may change over time and loading historical data
might cause problems?
It can be acceptable, because validation is done into domain it should not be the case. On a point of view of business, objects cannot be in an invalid business state, however, some times, like in the real life, process can be in an invalid/temporary state. We call it eventual consistency (https://en.wikipedia.org/wiki/Eventual_consistency), I suggest you take a look at this. At the end the system will be in a valid state and that's all that matter, if its temporarily invalid, well, the effort might be bigger to maintain such system but sometimes you have no choice.
Many implementations consider throwing exceptions in the domain layer
and mapping the messages to the UI although Martin Fowler recommends
to Replacing Throwing Exceptions with Notification in Validations!
When to return messages and when to throw exceptions in the validation
context ?
I am not a big fan of exceptions in the domain layer unless this is clearly a pre-requisite thesis broken. For instance an input too large for a field, or a negative price for an item. If you cannot build a valid business object, then in my opinion this is a very valid case for an exception. In case this is a business case, a message is best suited.
Many articles explain some tips or paths to follow like Vladimir
Khorikov and jbogard in their articles but in the comments they
confess that they do things a wee differently now. Are these patterns
still valid?
Should I use framework like FluentValidation and if I use it, Is this
frame work used only in the application layer as an alternative to the
MVC annotations ?
Best recommendations in DDD is to never use framework, Spring or JDBC might help however but in general you should do it by hand. We have written even stores by hand, application services and Oracle projections and event bus. Its more faster, more maintainable, and you learn a lot more. Vaughn Vernon in his book (Implementing Domain Driven Design) gives very good examples and a project you can look at: https://github.com/VaughnVernon/IDDD_Samples (written in Java)
When Should I use Business Rule Framework (BRF) instead?
Again, don't use a framework
There are actually several different activities that might be called "validations", and they are all handled somewhat differently.
Message validation usually happens as close to the boundary as we can manage. When I receive an HTTP request, I'm going to verify that the request itself is well formed, that the right media type is specified in the meta data, that the request body can be processed cleanly, that the resulting DOM has all of the required fields, that the known data nodes are all of the appropriate type, that the values present are within the allowed ranges, all before I worry about the current state of the domain model.
Often, this validation takes the form of transforming the data from the message into a graph of value objects in the domain; that will usually look like factories or builders that know how to take domain agnostic value types and convert them into domain specific values. The domain model won't normally know anything about the message format, and won't know about the serialization (JSON is not normally a domain concern).
There is a similar separation of concerns when reading values from the persistent store - the value factories will know how to create values from primitives, but won't necessarily know anything about JSON, or results sets, and so on.
The "business logic", which validates whether a given message is meaningful given the current state of the domain, usually lives within the domain model.
Is it acceptable for the object to be in invalid state?
It shouldn't ever be acceptable for an object to be in an invalid state.
BUT there are valid states that aren't reachable. Negative account balances are becoming a significant liability for the company, so a new business rule is introduced that prevents withdrawals that would result in a negative balance. That doesn't change the fact that Bob's account balance is negative. It's still a valid state, just one that isn't reachable with the new rules.
When to return messages and when to throw exceptions in the validation context ?
Don't use exceptions to implement contingency management.
There are straight answers for your questions. So I put the answers with no background.
In which layer should the validations be done mainly?
Both server and client side for more accurate and secure applications. Regardless of design context. For server side you may employ different ways like fluent validation or Data Annotation (Model) or bring them to client with integration libraries like jquery-unobtrusive-ajax. Server side validation is more important, since CRUD operations needs to be validated to avoid anomalies and etc ....
In terms of your question, layers are View and Model (Data Access).
Is it acceptable for the object to be in invalid state? because many
answers said that it's okay and mainly because of historical data and
the business rules may change over time and loading historical data
might cause problems?
It's acceptable, required fields or empty values for required dependencies fires error when you show or process data store in Database. Here, there is no speaking about changes which can be over time. We only consider now. We employ patterns and programming rules to create flexibility/maintainability. Validations and entry dependencies can be changed over time.
Many implementations consider throwing exceptions in the domain layer
and mapping the messages to the UI although Martin Fowler recommends
to Replacing Throwing Exceptions with Notification in Validations!
When to return messages and when to throw exceptions in the validation
context ?
Showing exception in client-side is a good technique for development days or notifying corresponding user about the error which prevents data to be changed/stored. considering that: some systems really have no strategy to show additional info to the end user. Some reports can make the app more vulnerable to intrude. This is completely based on the software type you are developing. A good practice is showing a simple error in client-side and store error logs inside server (with comprehensive details).
Many articles explain some tips or paths to follow like Vladimir
Khorikov and jbogard in their articles but in the comments they
confess that they do things a wee differently now. Are these patterns
still valid?
Some people may have personal architectures with their own naming. But some of them are official and widely used like Unit Of Work or Repository Pattern which add some layers to famous pattern (MVC) to achieve more accurate, clean and maintainable code/application. Follow the main purpose behind any pattern.
Should I use framework like FluentValidation and if I use it, Is this
frame work used only in the application layer as an alternative to the
MVC annotations ? When Should I use Business Rule Framework (BRF)
instead?
FluentValidation is an alternative to DataAnnotations working like the FluentAPI. Note that both used to define rules for properties belonging to a defined class (a database table). There's a concept named ViewModel which contains a transformation(with some changes) for Main Model class (Table) mainly targeting the validation in front-end. You may employ both for a project, mapping each Model to its ViewModel or vice versa. If you are using a repository pattern, say, have a Data Access Layer, So some of the validation is inside this layer. If you're using ViewModel, so it's inside application layer. But, As an advice, These are worthless. The key success is to understand main purpose behind any technique/architecture/pattern. You can find tons of article around each of them and focus on purpose, then you can decide what to do to have a more clean/standard/maintainable/flexible/etc... code.
And the Final Tip : Increasing the modularity increases the cost to integration (software cost) Although decreases cost for each module. Use a moderate design for your project. Combining architectures sometimes not only is not a good idea but also increases the cost and development hardships. More details in software design basics
I've been struggling with a design decision and was hoping for some feedback.
Architecture summary:
ASP.NET MVC WebAPI solution with a SPA frontend written in KnockoutJS and Entity Framework hooked up to a SQL DB.
The problem: we have two entities that pull a value (Rate) from a somewhat complex lookup table. The lookup table filters down to a distinct option based on 5 parameters, all 5 parameter values can be determined based on properties on each entity or a related table. On top of this look up value, both entities can have "Rate Modifiers" which can add another small amount to this lookup value.
The question: where should we put this lookup logic if we would like this calculated rate to be available anytime we use these two entities?
Service layer: have a service to request these entities, request
the entities from the Data (Infrastructure) layer repository, then
make individual calls back to the data layer to get the computed
rate
Data layer: inside the data layer repository get all the
entities and lookup the values there within the repository
UI layer: just send the entities to the UI layer and then have web
services to retrieve the rates for the 5 parameters
DB: Create a view in the db for these entities that does all the
rate lookup logic for us in the db
Other suggestions?
I see advantages and disadvantages to all of these options and none of them feel quite right to me. Option 3 feels like it's the cleanest, but is probably the least performant and is the most chatty. options 2/4 seem messy putting business-like logic in the data layer and option 1 feels a little over complex and inefficient.
Any insight would be greatly appreciated! Thank you.
If seperation of concerns or keeping everything clean is your concern, then it is best to keep it in the Service layer. Just as you suggested ,having the UI layer call the service layer which in turn calls the datalayer. The service layer is where the business logic usually lies. This is the ideal situation though.
However, if speed is your concern I think it is better to keep things in the DB layer probably as a stored procedure. In my experience this performs really well. But generally it is best not to spread business logic across layers.
Whatever solution you use , it is best to choose based on what your priority is - seperation of concerns or speed ,etc.
Do let us know what you went with.
In situations where the client consuming a web service is looking for data that at present matches a database entity one to one (ie. GetAccount, GetTransactions); we still want to use a data transfer object (dto) to decouple the two to allow the database entity to change if needed, without the changes rippling through the entire system? If so, from a consuming standpoint, we don't want a client's model directly based on the data transfer object. We would want to cast whatever was being returned from the web service to a local model, for the same reasons we used a DTO in the first place? Do I have that right?
The DTO matches the shape of the data that you want to transfer. If that matches the underlying data model then so be it but that is by the by. You might at some point change the shape of the underlying data model but the DTOs would not change.
Also, a DTO is what would get passed by a web service to a client. If you have your data model defined on a server then you don't want a distributed client to have to know about that data model.
Finally, your entity classes might contain additional logic whereas a DTO is simply properties exposing data and nothing else.
Your application can have many conceptual layers. Data Layer, Business Layer, Service Layer, Presentation Layer to name a few. Each has a specific function with an input and output. The goal is how to design a system that is loosely coupled (i.e. things don't rely heavily on one another so any changes are isolated and have minimum impact). You want to maximise maintainability, improve re-use and maximise speed. The trick is to keep complexity down but build in some basic separation that allows you to move your design forward easily as you need it. Keep in mind YAGNI! YOU AINT GONNA NEED IT! People tend to look for and design the most complicated architectures for problems they will never encounter! The number of times I have heard "We have a separate data tier so we can swap out the database in the future"...yet I have never seen it happen! A simple Repository Pattern works.
As per previous poster, you have data in the database (in a physical model) that you want to get into your application transformed into a conceptual model. Any clients will then consume your conceptual model. I would do this immediately at or after your application code has retrieved the data from the database from your data layer. This ensures any changes made to your database are isolated from the rest of your application. Therefore you don't have to start changing your User Interface because you have changed the name of a database field. You just have to update your data layer.
If you choose Entity Framework as your data access strategy it will map your database to a conceptual model for you. If you are converting other data objects from one type to another look at technologies like AutoMapper. You can map your Entity Framework POCOs to a service contract (XSD). From the client perspective 'you could' write a client proxy that calls your web service, maps the returned service contract to a nice shared conceptual object model.
Keep it simple. Keep re-use and simplicity at the heart of what you choose. If you start seeing database column names in your client objects, you need to start thinking about putting in some abstractions in much earlier in your solution to insulate your app from changes.
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.