Despite I google-d for some time I couldn't find any of the Model-View-XYZ framework implementations for server-side Blazor, that is Razor Components (XYZ stand for any of the following: Controller, Presenter, ViewModel).
If anyone knows of such an implementation, no matter in what stage of development it is, please let me know. Thanks a lot in advance.
EDIT: The question is if someone has encountered, or takes part in development of such a framework.
The question is absolutely simple - has someone encountered some info on the Internet about such a framework targeting Razor Components (aka server-side Blazor), since I haven't so far.
I'm not 100% sure what your question is so I'm taking a stab at what I think you're asking.
It's important to understand that Blazor is not opinionated about how you choose to structure your code. The team have been very clear that they will not force any patterns on developers. This means that you are free to structure your code how you feel is best.
If you're interested in MVVM for example, Jeremy Likness has a great blog post covering using this pattern in Blazor apps. But if you are looking for official docs covering this then you're out of luck.
Hope this helps, if not please clarify what it is you're looking for.
Blazor itself is an MVVM framework. The HTML in your Razor Component is your View. The #functions section is your ViewModel and you can use POCO classes for your Models.
I released HanumanInstitute.MvvmDialogs as a platform-agnostic solution to display dialogs. It's currently implemented for WPF and Avalonia.
Blazor support could easily be added by copying from the Avalonia branch. If someone wants to take on that task.
After reading about it I implemented this MVVM design for Blazor Webassembly + WebApi app. A ViewModel is injected as transient into the View and the View calls the ViewModel's Initialize() which causes updates to ViewModel's properties which fires property-update events which are handled by the View to update the presentation state. The ViewModel also handles user actions that come from the View. ResourceApi is injected as singleton into the ViewModel which subscribes to resource-updated events. Model caching can be implemented at the ResourceApi layer. An action that updates a resource raises a resource-updated event which causes the ViewModel to reload the data and in turn raise its own property-changed event which is picked up by the View to update the presentation using binding.
Related
I don't get completly the architecture of Titanium Alloy. Maybe someone can explain it better or draw me a picture? :)
What I understood is that it is a mvc architecture but not in the "basic" way... The Model is only a blueprint for the intern SQLite database. The Backbone Model also can be extended to check for correct input and duplicates. To synch with the extern the Controller is used. At least all the examples I found did that. And the View is basic with Titanium Style Sheets.
Unfortunately you have a very terse, incomplete understanding of what Alloy is, what it does, and how it does it. Fortunately for you though, there's is extensive and complete documentation that covers all this in guide form. Answers to all these high level architecture questions and more can be found here: http://docs.appcelerator.com/titanium/latest/#!/guide/Alloy_Framework
Well Alloy is indeed a framework that is based on the MVC architecture, maybe what you need is to get some insight on the design goals of MVC and how they can be achieved using the separate roles for each unit of software. Here is a very good article I would recommend: http://blog.codinghorror.com/understanding-model-view-controller/
The fact that you can specify view structures using only xml files and styling using only static properties means that Alloy is a very well implemented MVC framework as it does not allow you to mix the responsibilities of each role.
My 2 cents of understanding Alloy:
controller.js
Here place only code that handles ui element events such as clicks, taps and so on. Your controller should pick up an event and call a method belonging to some external common.js module that you should require using require(). It is fully supported in Alloy.
view.xml
Here you only specify the tree structure of your ui elements. This means what component belongs where and to which other component.
style.tss
Here you should specify anything that has to do with colors, position, layout etc.
After doing some reading on the Model View Controller pattern it seems that the pattern is implemented quite differently in web frameworks vs desktop frameworks. With web based MVC frameworks the view and model never communicate directly. They can only communicate with the controller. But in desktop implementations, it seems that the view and model can communicate directly which doesn't make sense to me. That would seem to defeat the purpose of MVC of having separate, clean, isolated layers. Plus, what does the controller do if the view and model communicate directly?
Here is a diagram from Wikipedia illustrating MVC.
Model-View-Controller
It's a funny thing that I wrote recently an article on my blog about the different implementation of the MVC concept in web frameworks.
You can read it here.
also there is Presentation-abstraction-control
I found this article that seems to best explain the issue. http://andrzejonsoftware.blogspot.com/2011/09/rails-is-not-mvc.html
It appears that there are really two architectures going by the same name: MVC and Model2.
Asp.net MVC 3 preview 1 was released at the end of last month. Are there any new features you are excited about or any features you would like to see before it is fully released?
Full support for Controllers with Generic Parameters
public GenericController<SomeType> : Controller
Generic controllers are quite possibly the greatest MVC timesaver if your doing a lot or business CRUD. There are so many similarities between the Add methods of almost every MVC project that it makes sense to abstract these operations out in a Controller that fits all scenarios.
Right now its a little hacky to create a generic controller. The MVC engine always gets the name wrong (GenericCo vs. Generic) and without full support plugin and libraries that interact with controllers just fall over when they encounter a generic one.
Make Dropdowns easier to work with
As a professional MVC tag watcher I've noticed that working with dropdowns is one of the most repeated questions on SO. The amount of Dropdown questions is a strong indication that something should be done to make it easier or less ... complex?
make checkbox list easy to work with
add T4MVC to the official release
add official helpers for OData
support one javascript library either MS Ajax or jQuery(preferably)
I wish they can add something to help developer to migrate their previous ASP.NET WebForms application.
Seems like every project I'm on uses a Model View Controller architecture, and that's how I roll my own projects. Is there an alternative? How else would one create an application that has persistent storage and a user interface?
MVC has been around for a while. It's a time tested and proven pattern. Many frameworks leverage the MVC Pattern. Martin Fowler has deconstructed the MVC into: Supervising Presenter and Passive View.
Architect Christopher Alexander said it best:
Each pattern describes a problem which
occurs over and over again in our
environment and then describes the
core of the solution to that problem,
in such a way that you can use this
solution a million times over, without
ever doing it the same way twice.
I'm not sure why you would want to move from MVC. Is there a problem you are encountering that MVC does not eloquently solve? To give you a better answer we need to know more about your problem domain.
Things to take into account when considering patterns/architecture: If you are building something with a Myspace type architecture you'll need a robust architecture (MVC). If you are creating a simple crud interface via the web - almost anything will do.
For .Net Web forms (I am assuming web, since you didn't say thick or web client) which is not MVC, it was a nightmare maintaining them. Web Forms applications that lived more that a couple years tended to become big balls of mud. Even then developers discovered ways to use MVC with web forms.
Ironically, the lack of MVC architecture in ASP.NET web forms was one of the driving complaints that lead to the development of ASP.Net MVC framework.
From experience if you don't use some MVCesk approach, your solutions become hard to maintain and bloated. These applications will die a slow painful death.
If your solutions are small one-off projects, the by all means throw something together. Heck there are tools that will generate everything from the screens to the data access layer. Whatever works to get the job done.
Classic CRUD apps built using tools like VB6 and Delphi have user interfaces, persistent storage and don't use MVC. Most of them used data aware controls linked directly to database fields
Couple of links comparing various MV* patterns which might be useful:WPF patterns : MVC, MVP or MVVM or…? & MVC, MVP and MVVM
Look into MVP model view presenter.
User interface is View and an application will always have a model and the bridge between the two is Controller. The whole MVC is nothing special as this is how the things will be always.
At the most you can get rid of Controller and have your view talk to your model but you loose the flexibility.
I've developed an alternative to ASP.NET MVC. You get the same loose coupling and separation of concerns but the difference is in how you go about building your projects.
I have a couple of videos on my blog, source code for the framework, a sample project and a few VS.NET add-ins (New Project item, New Builder and New View).
Builder for ASP.NET
Some key differentiating Features are
1. Templates are just html - no code mixed with templates
2. Templates are thus reusable across views and Web site designers can design templates in their design tool of choice
3. Strongly typed code (no ViewData and stuff) so you get intillisense, compile time checking, F12 navigation etc.
4. You build pages as compositions of views rather than an inside-out approach
5. View can be treated as "real" classes.
6. Everything is complied so no run-time compilation
Quite a few other differentiating factors as well.
In theory :
MVC is a proved technology and yada-yada-yada, and it is ideal for websites.
But in a real case:
A serious project that use MVC required a framework, hence you are following a framework with all their limiting and restrictions. So, at this point, the specific implementation of MVC is rule and not a simple "guideline".
Also MVC fail miserably for websites when it is about to connect to the model other than simple POST/GET, it fail with xml asynchronism and it fail with ajax. (*)
(*) exist some patch but a design must be clear and functional and if you need to "patch it" then it is neither clear nor functional.
Personally i think that the main problem with MVC is that it put so much effort in the Controller, where most project use not more that 5 lines for the controller part.
ps: Most "well done" MVC projects are 3-tier project.
ps2: MVC excluding some framework, is just a buzzterm, IS NOT A SERIOUS TERMINOLOGY and it is reflexed in the group of "interpretation of mvc".
What are your favourite patterns for writing a controller?
This is rather a tough question as MVC is applied differently in different contexts. For example, for a desktop GUI, you might have listeners for event notifications of view changes but such behavior typically isn't used for Web forms (AJAX is changing this).
For the Web, you generally have:
Model: business logic
View: presentation logic
Controller: application logic
The controller should generally be minimalistic and if you find yourself pushing display information or business rules in it, there's probably a design flaw somewhere. Classic examples of such flaws in the controller are building HTML (view) or accessing the database directly (model).
I've written up a more thorough description of MVC on my O'Reilly blog. I have concrete examples there which can help explain things a bit more in depth.