Sorry, if it's kind of newb question. Please, help me to correctly name the architectures I described below.
Lets take we had web-application built with Spring framework/Hibernate/Thymeleaf(or another template engine) with the code of controllers looked like:
#Controller
public class AboutController {
#GetMapping("/about")
public String aboutview (Model model) {
return "about";
}
So, this is pure MVC software design pattern, as I take.
After this we switched from Thymeleaf to ReactJS for UI. So colleagues asked me to make few REST endpoints, which was used later for drawing single React's page. To be more concrete, let's take this controllers produced a filtered list of the users and goods, which was gotten from the JPA Repository.
So, the questions are:
To which architectural pattern did we switched off instead of pure MVC in above mentioned sample?
If it wasn't HMVC (hierarchical MVC), how it supposed to be looked like in term of controllers? Is it should look like few REST-controllers, which calls each other or simultaneously being called from React?
If I have few microservices, which has endpoints being called from the one React's page (or whatsoever JS framework), how can I correctly name an architecture of the Application: "microservice app with MVC pattern?"
Architecture of a software system is about what components exists in the system, how its components arranged. Of all the components, some of them will be in the same process communicating through function calls. Some of them will be in the same computer but running in different processes. (In this case, they will talk through OS provided inter-process communication). Finally, Some of them will be running in different computers of a network. (For instance; internet) [In this case, they will talk over a network through network protocols(for instance; http) using sockets]
Spring regular MVC or Spring REST Controllers are all about how the VIEW component and the component providing access to system functionality talk to each other and what computer VIEW and component providing access to system functionality runs in.
There might might be many more components which VIEW does not know about because of the fact that VIEW is isolated from other components through back-end API. (This is true for both classic MVC and REST controllers)
For instance; classic MVC or REST controllers might be run against a database or a file and that would not effect the VIEW. There might be a KAFKA broker and that would not effect the VIEW. (In terms of functionality).
When you write your back-end using REST API, mobile applications and other applications can consume that API. Classic MVC can only be consumed by a browser.
Related
Imagine I have a Razor Page or such like. Imagine the data used by that Razor Page is not used by any other page at all. So the data retrieval is very specific to this page only.
Is it bad practice to just grab the data directly using a database connection from within that Razor Page local to the only place that data is to be used?
If so, why should I abstract the data away into a separate API that isn't re-used anywhere? Why is it good practice?
It seems to me, that REST APIs are sometimes used unnecessarily and for no good reason. As if because every example video shows data retrieval from REST APIs. Correct me if I am wrong.
If your application is purely a server-side app, there is no justification for creating RESTful API that serves up JSON for it. Those kinds of APIs are usually created for "external" consumers, by which I mean third parties or the browser (via JavaScript). They are commonly implemented for client side apps - single page apps typically like React, Angular or Blazor where JSON is the data format of choice for the browser.
As to whether you should open database connections in your PageModel class, that's another question. For simple apps, why not? But for apps that need unit testing, it's not a good idea. You will be unable to execute unit test against the PageModel class without hitting the database.
As a habit, I tend to put the code that connects to a database in a series of separate classes, each one having an interface, and then inject them into the PageModel via dependency injection. That way I can mock the service represented by the interface for unit testing.
You might want to implement services that generate data as JSON within a Razor Pages app if you have some functionality that depends on Ajax requests for data. For those, you could use Web API controllers, minimal request handlers or even named handler methods that return JsonResult objects in the PageModel classes. With all of those, you might still want to put the code that actually calls the database in a separate class that is injected into the handler.
I am currently developing a Xamarin Forms app and am in the process of reworking it to work with Prism. I'm really trying to adhere to MVVM design patterns (I'm trying to grow as an amateur developer and learn how to use them).
1) Is it improper from a MVVM design pattern perspective to utilize messaging services (Prism's EventAggregator) and UI interactions (Prism's PageDialogService) outside of VMs? I've written several "services" that are called from the VM and have found a need to access both messaging and UI services. As one example, The VM calls a service, the service retrieves and processes some data, ask a question to the user based upon those calculations and then continue to finish processing returning the desired value. To be proper, should control be returned back to the VM to "just" ask the question?
2) If it's not verboten, is it possible to access the services outside of VMs? It does not readily appear to me that I can inject them into the constructor of the service. Is it okay to "pass" them into the service's function I'm calling along with other parameters? That just seems un... MVVM-ish?
Update:
I'm not sure all my steps were necessary, but with the help below I got it working. First I converted my singleton service into an interface (IMyService) and an implementing class (MyService). Next, I overrode ConfigureContainer in App.xaml.cs and called Container.RegisterType<IMyService, MyService>(new ContainerControlledLifetimeManager());
I could then inject IMyService, just like IEventAggregator and IPageDialogService into my ViewModels and I could also inject those services into the public constructor of my implementing class (MyService).
ad 1) the event aggregator is meant primarily for UI, but you can use it as message bus in other parts of the app, too, if you don't need the more advanced features of a "real" message bus.
ad 2) unity will happily inject dependencies into services that are themselves dependencies of view models or other services. That's what a dependency injection container does :-)
I'm building a WPF application using MVVM pattern, and Caliburn.Micro is the framework choice to boost up the development.
Different from a conventional MVVM-based application, I add a business layer (BL) below the ViewModel (VM) layer to handle logic for specific business cases. VM is left with data binding and simple conversion/presentation logic. Below BL is an extra Data Access layer (DAL) that encapsulates the Data model (DM) underneath built with Entity Framework.
I'm pretty new to both WPF, MVVM and, of course, know almost nothing about Caliburn. I have read plenty of questions and answers about the Caliburn usage and now trying to use what I've learnt so far in my application.
My questions are:
Does it sound okay with the above layered architecture?
In the application bootstrapper, is it correct that we can register all services that will later be used (like EventAgreggator (EA), WindowManager or extra security and validation services), and also all the concerned VMs? These should be injected into VM instances via constructors or so (supposed I'll be using SimpleContainer). So from any VM that are properly designed and instantiated, we can have these services ready to be used. If I understand correctly, Caliburn and its IoC maintain a kind of global state so that different VMs can use and share it.
Navigation: I know this topic has been discussed so many times. But just to be sure I'm doing the right way: There'd be a ShellViewModel acting as the main window for the whole application with different VMs (or screens) loaded dynamically. Each VM can inherit either Screen or ViewModelBase or NotifyChangedBase. When I'm in, let's say, VM A and want to switch to VM B. I'd from inside VM A send a message (using EA) to the ShellViewModel, saying that I want to change to B. ShellViewModel receives the message and reloads its CurrentViewModel property. What should be a proper data structure to maintain the list of VMs to be loaded? How can stuffs like Conductor or WindowManger come into the place?
Can/Should Caliburn in one way or another support the access to the database (via EF). Or this access should be exposed to VM and/or BL only?
Thanks a lot!
Different from a conventional MVVM-based application, I add a business layer (BL) below the ViewModel (VM) layer
That's the standard case. ViewModels can't/shouldn't contain business logic which is considered to be part of the Model (Model in MVVM is considered a layer, not an object or data structure) in the MVVM. ViewModel is for presentation logic only.
Yes, as long as your Business (Domain) Layer has no dependency on the DAL (no reference to it's assembly). Repository interfaces should be defined in the Business Layer, their implementations in the Data Access Layer.
Yes, Bootstrapper is where you build your object graph (configuration the IoC container).
Registering ViewModels: Depends on IoC framework. Some frameworks let you resolve unregistered types, as long as they are not abstract or interfaces (i.e. Unity). Not sure about Caliburn, haven't used it. If the IoC supports it, you don't need to register them.
One possible way to do it. I prefer navigation services though, works better for passing around parameters to views and windows that are not yet instantiated and you always know there is exactly one objects handling it.
With messages, there could be 0, 1 or many objects listening to it. Up to you
What do you mean with support access to the database? You can use it to inject your repositories and/or services into your ViewModels, other than that there isn't much DB related stuff to it.
So we are focusing on developing a enterprise web application that utilized DDD patterns with CQRS+ES. We have a pretty good handle on that from the enterprise level. Now when we want to open up our backend services to native mobile devices using Xamarin and portable class libraries how does this come together? Do we change our domain projects in each of our bounded context to be a PCL project type? What do we do with the MVVM side of things for instance in Windows Store App, Windows Phone app? Since we are pulling from a Web API service do we pull in the PCL bounded context library or do we make a subset domain model and a separate PCL library for our native client MVVM patterns?
Right now we are leaning towards leaving the original DDD projects as class libraries and just creating a separate portable class library for our MVVM code. We will probably use file linking to link back into the domain projects to get the models so that we always have the latest set of POCO objects and any DTO objects we want to use on the client. Any one else have any thoughts or ideas on this? I really don't see a lot of discussions around this DDD+PCL combination.
I have done a lot of thinking about this and what i did to put Xamarin in my current architecture with DDD approach was:
Put your Domain Entities in a PCL project and use it to reference in all projects that you need, such as Xamarin.Forms, Xamarin.Android, Xamarin.iOS, ASP.NET, WCF, etc.
Your Domain Services can be in a normal class library that will be used for the Application layer. The application layer will be used by the Presentation projects such as ASP.NET MVC.
In the Distributed Services layer you're going to expose your services for Xamarin or other apps to communicate with your application. You can use ASP.NET Web Api or WCF with REST. This layer will also use the application layer respecting the DDD concepts.
The xamarin projects go in the presentation layer but do not use application layer. Here you will write your services for Xamarin to connect to your Distributed Services Layer through the internet. If you need offline sync you can also put that in here. Here you're going to reference your Domain Entities Project and have all your entities with their business rules.
This way you have your domain and business rules shared with all your solution and respecting DDD concepts and role separation.
I want to start new application on ASP.NET MVC4 using different different approach like domain driven development , design patterns , dependency injection , Entity Framework as ORM etc.
Need some advice on what should be the starting point of development? Should I start with first relationships of classes or start with traditional approach?
e.g there are three module.
User Management.
Logging.
Error Logging.
Should I first complete with user management like domain classes then its services and then its CRUD operations in actual web application? and after that ...will start with logging (same process as mention in user management). and then in error logging as well.
So What are best practices to start development using those kind of concept or tools?
ASP.NET MVC4 is just a presentation part of solution. With Domain-Driven approach you start with domain (usually separate library project) and then add presentation (web site, desktop application etc) and persistence (implementation of repository and uof interfaces declared in your domain).
So, you start with creating domain model (not whole, but part of that). Then in any order you create UI which uses you domain model, and implementation of repositories for persisting your domain model via Entity Framework. Well actually views should use ViewModels (otherwise your POCO domain objects will be polluted with Data Annotations attributes and other stuff). It's a controller part where you will use domain model. Also you will inject repository implementations to controllers via dependency injection.
I would start by looking at the business functionality requirements of the system and focus on the highest value requirements first. Implement those, filling out your business domain as you need to, based on delivering the requirements. If you follow a BDD style process, you can use unit tests to drive out the business functionality and your domain will evolve as the business requirements evolve. Each business requirement should have a UI and data access component to it so you can fill out the presentation layer and data access layer with Entity Framework as the domain evolves. Here's a couple of useful posts on BDD:
BDD By Example
Introducing BDD