Related
How to implement the mvvm architecture in objective-c ? I need sample project to learn the mvvm architecture and also i need to know that what is needed to give in model, view, viewModel and how to separate in objective-c ? what is the difference between the normal project and mvvm project ?
Jesto I can give you details about what you ask briefly.Even if it is explanation you can easily understand what I post here because it has sources with examples and you can directly try the source.
First the Model
The model layer is not as self-explanatory as it may seem.
As you would expect, it will have your model objects, potentially
covering most of the layer surface. In the tickets example, you would
have a Ticket struct that would live in your model.
I find the following components to also be part of the model layer:
Network Code. The shape should be something like this. Ideally, you’d only use a single class for network communication across your
entire app.
Persistence Code. You would implement this with Core Data or simply by saving an NSData blob directly to disk.
Parsing Code. Any objects that parse network responses and the like should be included in the Model layer as well.
While the model objects and the parser are domain-specific, the
network code will be highly reusable.
The controller will then use all the elements in your model layer to
define the flow of information in your app.
Second the View
When a user interacts with your app, they are interacting with the
view layer. The view is considered the “dumb” part of your app, since
it shouldn’t contain any business logic. In code terms, you’ll
normally see:
UIView subclasses. These range from a basic UIView to complex custom UI controls.
A UIViewController (arguably). Since a UIViewController is strongly coupled with its own root UIView and its different cycles
(loadView, viewDidLoad), I personally consider it to be part of this
layer, but not everyone agrees.
Animations and UIViewController transitions.
Classes that are part of UIKit/AppKit, Core Animation and Core Graphics.
Typical code smells found in this layer manifest in different ways,
but boil down to including anything unrelated to UI in your view
layer. A classic code smell is making a network call from a
UIViewController.
It’s tempting to put a bunch of code in your UIViewController and be
done with it, so you can meet that deadline. Don’t do it! In the short
term, you might save a couple of minutes, but in the long term, you
could lose hours looking for a bug, or have trouble when you want to
reuse code inside one view controller in another.
Third MVVM
Model-View-ViewModel, or MVVM, is an MVC derivation. Conceptually,
it’s similar. The biggest difference is in the communication between
layers, and instead of a controller, you use a view model.
In practice, MVVM shines when it has an FRP framework to support it.
Since the model is now observed by the view model and the view model
by the view, the FRP paradigm becomes a natural choice to manage the
information flow. This leads to a better separation between layers,
which translates in decoupled components that are easy to test.
Bottom line: architecture is important, but in my opinion the right
programming paradigm will influence more the overall quality of your
code. It’s also important to note, that most often that not, you will
have in the same app different approaches. This includes both
architecture and paradigm. You might think this will disrupt
consistency inside the codebase, but you should always use the right
tool for the job.
Finally MVC
The Model-View-Controller (MVC) design pattern assigns objects in an
application one of three roles: model, view, or controller. The
pattern defines not only the roles objects play in the application, it
defines the way objects communicate with each other. Each of the three
types of objects is separated from the others by abstract boundaries
and communicates with objects of the other types across those
boundaries. The collection of objects of a certain MVC type in an
application is sometimes referred to as a layer—for example, model
layer.
MVC is central to a good design for a Cocoa application. The benefits
of adopting this pattern are numerous. Many objects in these
applications tend to be more reusable, and their interfaces tend to be
better defined. Applications having an MVC design are also more easily
extensible than other applications. Moreover, many Cocoa technologies
and architectures are based on MVC and require that your custom
objects play one of the MVC roles.
Difference between Normal and MVVM
Models — responsible for the domain data or a data access layer
which manipulates the data, think of ‘Person’ or ‘PersonDataProvider’
classes.
Views — responsible for the presentation layer (GUI), for iOS environment think of everything starting with ‘UI’ prefix.
Controller/Presenter/ViewModel — the glue or the mediator between the Model and the View, in general responsible for altering the Model
by reacting to the user’s actions performed on the View and updating
the View with changes from the Model.
MVVM Says
The latest and the greatest of the MV(X) kind The MVVM is the newest
of MV(X) kind thus, let’s hope it emerged taking into account problems
MV(X) was facing previously. In theory the Model-View-ViewModel looks
very good. The View and the Model are already familiar to us, but also
the Mediator, represented as the View Model. MVVM It is pretty similar
to the MVP:
the MVVM treats the view controller as the View
There is no tight coupling between the View and the Model In addition, it does binding like the Supervising version of the MVP;
however, this time not between the View and the Model, but between the
View and the View Model. So what is the View Model in the iOS reality?
It is basically UIKit independent representation of your View and its
state. The View Model invokes changes in the Model and updates itself
with the updated Model, and since we have a binding between the View
and the View Model, the first is updated accordingly.
Also the MVVM Design Pattern and How does MVVM work?
Check it out this topic -> What is the difference between MVC and MVVM?
Model-View-ViewModel basic example is here -> https://github.com/futurice/mvvm-example-objc and maybe next step, you can use reactive cocoa because it can be more effective with mvvm -> https://github.com/ReactiveCocoa/ReactiveViewModel
reactive cocoa -> https://github.com/ReactiveCocoa/ReactiveCocoa
goodluck :)
I'm (re)designing large-scale application, we use multi-layer architecture based on DDD.
We have MVC with data layer (implementation of repositories), domain layer (definition of domain model and interfaces - repositories, services, unit of work), service layer (implementation of services). So far, we use domain models (mostly entities) across all layers, and we use DTOs only as view models (in controller, service returns domain model(s) and controller creates view model, which is passed to the view).
I'v read countless articles about using, not using, mapping and passing DTOs. I understand that there's no any definitive answer, but I'm not sure if it's ok or not returning domain models from services to controllers. If I return domain model, it's still never passed to the view, since controller always creates view-specific view model - in this case, it seem legit. On the other hand, it doesn't feel right when domain model leaves business layer (service layer). Sometimes service needs to return data object that wasn't defined in the domain and then we either have to add new object to the domain that isn't mapped, or create POCO object (this is ugly, since some services return domain models, some effectively return DTOs).
The question is - if we strictly use view models, is it ok to return domain models all the way to controllers, or should we always use DTOs for communication with service layer? If so, is it ok to adjust domain models based on what services need? (Frankly I don't think so, since services should consume what domain has.) If we should strictly stick to DTOs, should they be defined in service layer? (I think so.) Sometimes it's clear that we should use DTOs (e.g., when service performs lot of business logic and creates new objects), sometimes it's clear that we should use just domain models (e.g., when Membership service returns anemic User(s) - it seems it wouldn't make much sense to create DTO that is the same as domain model) - but I prefer consistency and good practices.
Article Domain vs DTO vs ViewModel - How and When to use them? (and also some other articles) is very similar to my problem, but it doesn't answer this question(s). Article Should I implement DTOs in repository pattern with EF? is also similar, but it doesn't deal with DDD.
Disclaimer: I don't intend to use any design pattern only because it exists and is fancy, on the other hand, I'd like to use good design patterns and practices also because it helps designing the application as a whole, helps with separation of concerns, even though using particular pattern isn't "necessary", at least at the moment.
it doesn't feel right when domain model leaves business layer (service layer)
Makes you feel like you are pulling the guts out right? According to Martin Fowler: the Service Layer defines the application's boundery, it encapsulates the domain. In other words it protects the domain.
Sometimes service needs to return data object that wasn't defined in the domain
Can you provide an example of this data object?
If we should strictly stick to DTOs, should they be defined in service layer?
Yes, because the response is part of your service layer. If it is defined "somewhere else" then the service layer needs to reference that "somewhere else", adding a new layer to your lasagna.
is it ok to return domain models all the way to controllers, or should we always use DTOs for communication with service layer?
A DTO is a response/request object, it makes sense if you use it for communication. If you use domain models in your presentation layer (MVC-Controllers/View, WebForms, ConsoleApp), then the presentation layer is tightly coupled to your domain, any changes in the domain requires you to change your controllers.
it seems it wouldn't make much sense to create DTO that is the same as domain model)
This is one of the disadvantage of DTO to new eyes. Right now, you are thinking duplication of code, but as your project expands then it would make much more sense, specially in a team environment where different teams are assigned to different layers.
DTO might add additional complexity to your application, but so are your layers. DTO is an expensive feature of your system, they don't come free.
Why use a DTO
This article provides both advantage and disadvantage of using a DTO, http://guntherpopp.blogspot.com/2010/09/to-dto-or-not-to-dto.html
Summary as follows:
When to Use
For large projects.
Project lifetime is 10 years and above.
Strategic, mission critical application.
Large teams (more than 5)
Developers are distributed geographically.
The domain and presentation are different.
Reduce overhead data exchanges (the original purpose of DTO)
When not to Use
Small to mid size project (5 members max)
Project lifetime is 2 years or so.
No separate team for GUI, backend, etc.
Arguments Against DTO
Duplication of code.
Cost of development time, debugging. (use DTO generation tools http://entitiestodtos.codeplex.com/)
You must synchronize both models all the time. (personally, I like this because it helps know the ripple effect of the change)
Cost of developement: Additional mapping is necessary. (use auto mappers like https://github.com/AutoMapper/AutoMapper)
Why are data transfer objects (DTOs) an anti-pattern?
Arguments With DTO
Without DTO, the presentation and the domain is tightly coupled. (This is ok for small projects.)
Interface/API stability
May provide optimization for the presentation layer by returning a DTO containing only those attributes that are absolutely required. Using linq-projection, you don't have to pull an entire entity.
To reduce development cost, use code-generating tools
I'm late to this party, but this is such a common, and important, question that I felt compelled to respond.
By "services" do you mean the "Application Layer" described by Evan's in the blue book? I'll assume you do, in which case the answer is that they should not return DTOs. I suggest reading chapter 4 in the blue book, titled "Isolating the Domain".
In that chapter, Evans says the following about the layers:
Partition a complex program into layers. Develop a design within each layer that is cohesive and that depends only on the layers below.
There is good reason for this. If you use the concept of partial order as a measure of software complexity then having a layer depend on a layer above it increases complexity, which decreases maintainability.
Applying this to your question, DTOs are really an adapter that is a concern of the User Interface / Presentation layer. Remember that remote/cross-process communication is exactly the purpose of a DTO (it's worth noting that in that post Fowler also argues against DTOs being part of a service layer, although he isn't necessarily talking DDD language).
If your application layer depends on those DTOs, it is depending on a layer above itself and your complexity increases. I can guarantee that this will increase the difficulty of maintaining your software.
For example, what if your system interfaces with several other systems or client types, each requiring their own DTO? How do you know which DTO a method of your application service should return? How would you even solve that problem if your language of choice doesn't allow overloading a method (service method, in this case) based on return type? And even if you figure out a way, why violate your Application Layer to support a Presentation layer concern?
In practical terms, this is a step down a road that will end in a spaghetti architecture. I've seen this kind of devolution and its results in my own experience.
Where I currently work, services in our Application Layer return domain objects. We don't consider this a problem since the Interface (i.e. UI/Presentation) layer is depending on the Domain layer, which is below it. Also, this dependency is minimized to a "reference only" type of dependency because:
a) the Interface Layer is only able to access these Domain objects as read-only return values obtained by calls to the Application layer
b) methods on services in the Application Layer accept as input only "raw" input (data values) or object parameters (to reduce parameter count where necessary) defined in that layer. Specifically, application services never accept Domain objects as input.
The Interface Layer uses mapping techniques defined within the Interface Layer itself to map from Domain objects to DTOs. Again, this keeps DTOs focused on being adapters that are controlled by the Interface Layer.
In my experience you should do what's practical. "The best design is the simplest design that works" - Einstein. With that is mind...
if we strictly use view models, is it ok to return domain models all the way to controllers, or should we always use DTOs for communication with service layer?
Absolutely it's ok! If you have Domain Entities, DTO's and View Models then including database tables you have all the fields in the application repeated in 4 places. I've worked on large projects where Domain Entities and View Models worked just fine. The only expception to this is if the application is distributed and the service layer resides on another server in which case DTOs are required to send across the wire for serialization reasons.
If so, is it ok to adjust domain models based on what services need? (Frankly I don't think so, since services should consume what domain has.)
Generally I'd agree and say no because the Domain model is typically a reflection of the business logic and doesn't usually get shaped by the consumer of that logic.
If we should strictly stick to DTOs, should they be defined in service layer? (I think so.)
If you decide to use them I'd agree and say yes the Service layer is the perfect place as it's returning the DTOs at the end of the day.
Good luck!
It seems that your application is big and complex enough as you have decided to go through DDD approach.
Don't return your poco entities or so called domain entities and value objects in you service layer. If you want to do this then delete your service layer because you don't need it anymore! View Model or Data transfer objects should live in Service layer because they should map to domain model members and vice versa.
So why do you need to have DTO? In complex application with lots of scenarios you should separate the concerns of domain and you presentation views, a domain model could be divided into several DTO and also several Domain models could be collapsed into a DTO. So it's better to create your DTO in layered architecture even it would be the same as your model.
Should we always use DTOs for communication with service layer?
Yes, you have to return DTO by your service layer as you have talk to your repository in service layer with domain model members and map them to DTO and return to the MVC controller and vice versa.
Is it ok to adjust domain models based on what services need?
A service just talks to repository and domain methods and domain services, you should solve the business in your domain based on your needs and it's not the service task to tell the domain what is needed.
If we should strictly stick to DTOs, should they be defined in service layer? Yes try to have DTO or ViewModel just in service later because they should be mapped to domain members in service layer and it's not a good idea to places DTO in controllers of your application(try to use Request Response pattern in your Service layer), cheers!
Late to the party, but I’m facing the exact same type of architecture and I’m leaning towards “only DTOs from service”. This is mainly because I’ve decided to only use domain objects/aggregates to maintain validity within the object, thus only when updating, creating or deleting. When we’re querying for data, we only use EF as a repository and maps the result to DTOs. This makes us free to optimize read queries and not adapt them to business objects, often using database functions as they are fast.
Each service method defines its own contract and is therefore easier to maintain over time. I hope.
So far, we use domain models (mostly entities) across all layers, and we use DTOs only as view models (in controller, service returns domain model(s) and controller creates view model, which is passed to the view).
Since Domain Model provides terminology (Ubiquitous Language) for whole your application it is better to use Domain Model widely.
The only reason to use ViewModels/DTOs is an implementation of MVC pattern in your application to separate View (any kind of presentation layer) and Model (Domain Model). In this case your presentation and domain model are loosely coupled.
Sometimes service needs to return data object that wasn't defined in the domain and then we either have to add new object to the domain that isn't mapped, or create POCO object (this is ugly, since some services return domain models, some effectively return DTOs).
I assume that you talk about Application/Business/Domain Logic services.
I suggest you return domain entities when you can. If it is needed to return additional information it is acceptable to return DTO that holds several domain entities.
Sometimes, people who use 3rd part frameworks, that generates proxies over domain entities, face difficulties exposing domain entities from their services but it is only a matter of wrong usage.
The question is - if we strictly use view models, is it ok to return domain models all the way to controllers, or should we always use DTOs for communication with service layer?
I would say it is enough to return domain entities in 99,9% cases.
In order to simplify creation of DTOs and mapping your domain entities into them you can use AutoMapper.
If you return part of your domain model, it becomes part of a contract. A contract is hard to change, as things outside of your context depend on it. As such, you would be making part of your domain model hard to change.
A very important aspect of a domain model is that it is easy to change. This makes us flexible to the domain's changing requirements.
I'd suggest analyzing these two questions:
Are your upper layers (i.e. view & view models / controllers) consuming the data in a different way of what the domain layer exposes? If there is a lot of mapping being done or even logic involved I'll suggest revisiting your design: it should probably be closer to how the data is actually used.
How likely is it that you deeply change your upper layers? (e.g. swapping ASP.NET for WPF). If this is highly unlike and your architecture is not very complex, you may be better off exposing as many domain entities as you can.
I'm afraid it is quite a broad topic and it really gets down to how complex your system is and its requirements.
In my experience, unless you are using an OO UI pattern (like naked objects), exposing the domain objects to the UI is a bad idea. This because as the application grows, the needs from the UI change and force your objects to accommodate those changes. You end up serving 2 masters: UI and DOMAIN which is a very painful experience. Believe me, you don't want to be there. The UI model has the function of communicating with the user, the DOMAIN model to hold the business rules and the persistence models deals with storing data effectively. They all address different needs of the application. I'm in the middle of writing a blog post about this, will add it when it's done.
I have some questions after reading an article called Layered Application Guidelines (http://msdn.microsoft.com/en-us/library/ee658109.aspx).
For example, I have an ASP.NET MVC application. In my application I have some Entities (Models), Repositories, UnitOfWork and DbContext. And some Views and Controllers as well.
How to split them into layers according to an article above?
As far as I understand, Views and (maybe) Controllers reside in a Presentation Layer. Entities (Models) in Business Layer and Repositories, UnitOfWork and DbContext in Data Layer.
Am I right or mistaken? I'm very-very unsure about it.
Thanks in advance!
Views and Controllers should reside in the presentation layer. Your models should also reside in the presentation layer. Models reflect a view model that is used for presentation only. Entities should represent data and should not be sent to the View. In the presentation later, the models should be populated from the entities. You are correct in that your DbContext and UnitOfWork should be in the data layer.
The way the layers are separated will depend on the scope of your application. For a small one, Areas may suffice. For a larger project, or a project which may become large, you should look into creating separate solutions for each layer. This is known as an n-tier approach, and can be seen when looking at the excellent example at http://prodinner.codeplex.com/.
View models/Views/Controllers - presentation layer
Entities - business layer
The repository mediates between the data source layer and the business layers of the application
The DbContext Represents a combination of the Unit-Of-Work and Repository patterns, so if you are implementing a repository and unit of work on top of it could mean that you should consider to limit your abstractions. (This last point may not apply in your case, I couldn't say without knowing more about your design).
Entity Framework entities (along with the framework) are your data layer. In many applications they also become part of your business layer - and it is debatable whether or not this is good (I personally don't like that, but when you abstract it with say the repository model there is a good argument that you are losing some of the benefits provided by EF).
Depending on how you separate out your code (and it sounds like you are using the repository pattern) you may have a repositories containing some business logic, or have a services layer as well (my preference for 3 tier applications) where business logic (mostly) happens.
I would argue that you should be considering View Models as well as part of your presentation model - but if you are using MVC and data-annotations (which are excellent for this job) to validate your model you have just piled a bunch of business logic in to them.
The most important place to prevent business logic from creeping into is your presentation layer, and most importantly your Views and Controllers. The approach to how you structure the rest of your application depends heavily on the framework you choose, the scale of your application and the deployment structure of the application.
So to be as clear as possible this is what I do*:
Views <--Presentation layer only
Controllers <--Presentation layer only (might end up with slightly 'fat' controller in some instances, e.g. .NET Membership login)
View Models <--Presentation layer, but if doing validations here often business rules are also being tested.
Service Layer <--Business Layer if used
Repositories <--Could be Data layer only, or mix of business layer. If you do the repository pattern try and avoid exposing your DbSets directly, as this immediately defeats the abstraction you are attempting to provide (potential exceptions to this, e.g. - .Net Membership)
Entities <--Data layer, possibly with also business logic depending on how you structure your application.
*Not to be taken as authoritative
I'm new to asp.net MVC and EF, so excuse me if my question is not clear or easy.
I have read some tutorials about EF Code-First approach and now I'm trying this tutorial Getting Started with EF using MVC.
Using Code-First approach I'm using the POCO classes to define my DB model, DB logic, DB validation, UI validation and some UI logic. So I can use these classes(or objects) in my presentation layer or use them as JSON objects when dealing with Web-Services(or in JavaScript code).
My question: Isn't that mixing some logic together? I mean shouldn't I use like special view-model classes for presentation and these classes should have the UI logic and validation ?!
Is it good practice to send the POCO object to the view(or to the client in general) ?
Finally i need some guidance on how to organize my project layers or folders? I see many ways and I'm confused about what to choose or what format I should base my own on?!!
You should not use your data entities in higher layers of your application. Transform/compose/copy data from DAL into view model or business classes using a library like Automapper. This keeps the layers of your application independent and hides your database schema from end users.
Keep in mind that MVC is only concerned with presentation, all real work should happen in other layers of your app. I try to keep layers independent and use a little bit of glue code to bundle them into an app. I may write data access and business logic layers when working on MVC project, but then re-use in a command line utility. There are a lot of books that talk about writing quality code. I personally found Clean Code, Code Complete 2, and Design Patterns extremely helpful.
As LeffeBrune said, is bad practice to show directly your data entities to the presentation layer, you can try to expose some interfaces in form of project services that return the view model to the controller. This can help to keep the layers separate, and implement Unit of Work pattern and some other cool stuff.
You can start reading the Scott Millet Book
ASP.NET Design Patterns
for a starting point in designing a good layered application, here his blog.
You can define interfaces in your business layer which your EF entities can implement; the business logic doesn't know about the actual implementation. To do this you need the data layer to reference the business layer which means you're inverting the dependencies - you then use an IoC container to bind the interfaces to their implementations. ...but yeah that's one of many, many ways to go about it.
The thing is, with single responsibility in mind, your entities shouldn't worry about UI stuff - this can mean your interfaces also need to be implemented by "view model" classes, which implement things like validation and other business & presentation concerns.
Your questions require a lot of discussions.
Choosing infrastructure for your project is a complicated issue that depends on lots of factors. There are some design patterns that address different requirements in a project which involve you or your team in multiple concepts and technologies. I recommend you two valuable resources that help you understanding software architecture focused on .Net technologies.
CSLA.NET : The CSLA .NET framework is an application development framework that reduces the cost of building and maintaining applications. Rockford Lhotka, createor of CSLA.NET, has some books that deeply describe an optimal infrastructure of a project; all of your questions have answered in his books.
Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App: the project/sample is willfully restricted to .NET implementation of most used patterns in N-Layered Domain Oriented Architectures based on simple scenarios easy to understand (Customers, Orders, Bank Transfers, etc.). The project/sample is very well documented and all of your questions , also, have answered in the project.
All in all, view-models, POCOs, layers, etc. are concepts that have root in software architecture and I believe that they can not be described in short.
What I normally use is a POCO layer to use in my data access and a view model layer to use in my views just as LeffeBrune said.
All my layers use POCOs and the controllers are responsible to construct the view model that each view needs.
To get this work more automated I use automapper.
So my solution structure gets usually to be like this:
Model (POCO)
Data access (NHibertante)
Service (Business Layer)
Web (UI)
ViewModel
I've never worked with MVC design pattern before and recently I started to work on the project using ASP.NET MVC.
I'm using ActiveRecord as my data layer.
I'm also using view models (unique for each view) and AutoMapper to map my view models to EntityFramework entities.
In a few days reseaching about MVC, EntityFramework and reading different articles I came up with the following design:
In my solution I have Web project (Presentation Layer) which contains Views and Controllers.
I have Core project where I define my ViewModels and Services (Business layer where all business logic goes)
I have EntityModels project where all me EF entities live (Data layer)
This design allows me to keep my Data layer separate from my Presentation layer, Web project doesn't know anything about EntityModels project and vise versa, all the logic lives in business layer.
From my controllers (after validation checks) I pass viewModels to Service layer where mapping and all necessary busines logic is executed.
Is this design correct at all?
My consern is that I've read that ViewModels should be defined in Presentation Layer. I saw examples where Presentation Layer has references to Data layer and mapping is done in controllers (good practice?). in this case controllers pass domain models to business layer. I don't have any experience here but I don't like it.
So, can anyone point out where I'm right and where wrong?
thanks in advance.
Overall the architecture looks good. The decision on where to place you view models hinges on one factor in my opinion.
Do you plan to have other clients in the future that may benefit from reusing those view models (iPad, Android, etc.)?
If so, definitely keep them out of the MVC assembly and put them in their own assembly. Otherwise, you're safe putting them in the MVC app as long as you're ok with moving them and changing code if you ever decide to make a second client.
For the record, I always put my view models in their own assembly. It doesn't take more time up front, but it pays dividends down the road if things change.
FWIW, I am doing the same thing - but I am new to MVC, so not 100% sure I'm on the right path also. But, it just "feels right", which more often than not tells me it is correct.
The only thing I would add is that I use automapper (automapper.org), which almost eliminates the overhead of having the layers. Definitely check it out IMO.
I have to say the only thing that doesnt feel 100% correct is that with this pattern, we are creating a whole lot of ViewModels -> one per View. I assume you mean that Create, Index, Update, Details for each domain entity EACH have their own ViewModel? Or are you sharing one ViewModel between the views?
Lastly, I dont buy jfars argument that it creates lots of complexity/build time. At the very least, it conceptually separates the layers that much more. It strikes me as a much better job of separating the concerns, with very little overhead.
I have a pipe dream of reusing the viewmodels for a silverlight implementation, but havent really thought that one through yet. But it makes sense that if you do a good job of factoring out all "non-UI" code into the viewmodels and services, then doing a new UI should be "trivial", right? we'll see :-)