General question, when do people access their DAL in a prism application?
That is to say, if a module requires data do you query the DAL on the module load (I've currently been using OnImportsSatisfiedandINavigationAware.OnNavigatedTo` (passing in a parameter from the previous view).
Obviously I wouldn't want different modules to be tightly coupled but for an example where I have multiple views in a module would it be better from the UI responsiveness point of view to retrieve the data up front and pass it into the new view?
Anyone got any thoughts on this that they could share? Thanks.
In my current project we build the application this way that all view models asynchronouls query their data from one wcf service proxy after their own initialization. The proxy itself queries them from the server and caches it internally. Thus you have to think about a caching strategy.
But this leads to the following behaviour: The user interface is build up by the region manager. At the beginning it is empty. After a short time the data arrives from the server, the view models get their model, read the data from it, the data context of the view (which is the view model) is filled up and so the view is populated.
The answer to your question is: The view model queries the DAL (in my case the wcf service proxy) after it's creation in asynchronous way.
Related
I am in the process of creating a simple application with Spring Mvc and thymeleaf and I am currently thinking of what functionality I want to implement but I don't know exactly how to do it.
Let's say I have a model class Person. Regularly I have a form and a controller where I am passing the new person object and persist it with JPA.
No problem there but what if I want to have a page that I give some of the person basics info and then hit the "next" button and give some additional information. Then hit "next" again, review the data and hit "save"?
You can do it by integrate Spring Webflow in your project.
Webflow is basically extensive part of WebMvc. Webflow has some configuration that, where you have to start and where you should go. If you have 5 page and you would like to all these data will put into database in one process then Webflow will help you. One more advantage is, you can add validation in particular pages and particular means you have five model and all these model will work in one flow.
Read more, https://projects.spring.io/spring-webflow/
I have not used Thymeleaf, but usually this kind of problem can be solved using some of the following methods or something similar:
1.) Save the unfinished data to database using the same schema or some other schema for this (or in session; in general sense, save it somewhere on server side). Problem with this is how to get rid of abandoned data where user has not moved to finish.
2.) Drag the data from page to page with request parameters. If the requests are of type POST then just in POST body, if they are type GET then as query parameters. Problem with this is it's not very clean.
3.) Don't do full page requests. Solve it with some front end solution using Javascript. Depending on the app it might or might not be possible.
4.) Do full page requests but still solve it in front end using local storage or session storage. Similar problems as with keeping the data in server side session.
I'm creating a web app using an MVC framework. I thought of adding a layer between the controller and the domain models, I think it's called application layer in DDD, to avoid putting logic that is specific to a certain use case in the domain models.
The controller will only interact with this layer and this layer will orchestrate the operation using the domain models. This layer will be kept as thin as possible pushing all the logic that is not use case specific to the domain model.
I will call the classes that belong to this layer DomainCtrl.
Example login scenario:
Model: LoginForm
DomainCtrl: AuthCtrl
UI: ui controller
1.ui controller receives request
2.creates instance of AuthCtrl
3.AuthCtrl creates instance of a LoginForm and fill it with request data passed to authCtrl
4.LoginForm performs the login
5.authCtrl does other things that are specific to this specific way of login -> returns errors to ui controller
Is this a good way to organize an app?
Your question
Is this a good way to structure an app
is a very loaded question. The simple answer is Yes, but the more correct answer is It depends.
Let's start with the simple answer. Having your main application be unaware of the UI is generally a good idea. It means that you can easily consume your application from various places. In DDD this outer layer is usually called Application Layer. It is mainly responsible for orchestrating interactions between your domain, persistence and other resources that you might rely on. This also allows you to have your domain at the center unaware of everything else. This makes your domain easily testable and maintainable if implemented well.
Now the "it depends" part of the answer. DDD is not the only successful way to build an application, and in some cases it might be more of a hinderance than anything else. You have to ask yourself what is my app doing. Are there many domain specific rules? Am I only fetching and storing basic data etc? These are all questions you need to answer before you choose an architecture and technologies.
I would still say you probably won't go wrong by choosing the DDD approach as it is generally a good way to do things.
*Note: Your example is not that clear to me but you should be careful of spilling UI concepts into your domain/application. A login form is completely a UI concept as is auth to a certain extent. You can probably have your application return the details of your user, but the UI layer should decide if the user is allowed to proceed or not.
At a high level view, Yes
But it ultimately depends on "how" you logically separate your layers. In your scenario, I don't see any application layer.
I assume AuthCtrl is the domain? Who creates AuthCtrl? what layer does it exists?
I am developing for learning purposes my very first "big" Spring MVC project. I am learning everything by myself (and of course, thanks to this amazing community).
What I am starting to wonder is... Is my design "correct/valid"? So far I am creating one Controller per View/Page specially because of the ModelAttributes (attached to the method).
Is that fine? Should I start doing it in some other way? Are there "offical" patterns in this matter?
To start, I assume you are creating a web project based on your use of ModelAttribute. You want to follow the MVC (Model, View, Controller) convention. The "Model" is the data you are manipulating. This data should be retrieved via a service layer. Then, your controller should call your service methods to get the data, making your controllers completely agnostic of your data. This is nice because you are free to change your data structure, e.g. migrating from MySQL to MongoDB, without worrying about changing your controller, all you need to change is your service layer. Also, this allows for controllers to use many different services in certain instances. Your controller receives requests from the client, e.g. the website user's page requests, GET/POST requests, etc., and performs some action, usually fetching/updating data via the service layer, and then returns a view. Each controller can take many requests, and can render many views. It is good practice to break up controllers by function. For example, if you had two different sections for your website, one for Admins, and one for Guests, then you may want to use one controller to process the Admin requests, and another to process the Guest requests. Each of these controllers can handle all requests from Admins/Guests accordingly. You may be a bit confused about controllers. Each method in a controller is bound to a single request/view, but a controller may have many such methods.
As you are learning, I would suggest exploring some client-side mvc frameworks like AngularJS. Angular allows very easy data binding and manipulation options, and makes it pretty easy to create RESTful web services.
I am working on a business application which is being developed from scratch. We have opted to design our business logic using Entity Framework, and since the application has to be delivered on the Web we have selected MVC 3 (Razor) for presentation.
Things are pretty fine yet, but I am afraid how will I manage if anytime in the future we need to change our Entity Classes (like adding/removing fields in the business entities or adding more relational entities etc.). I know I can update my model by selecting "Update Model from Database" in Visual Studio (we are using Database first approach). In this case will I have to scrap my old views and generate new ones or is there any way I can update my exiting views.
That questions a little ambigous, so I'll talk about MVC concepts
The whole approach of MVC is "serperation of concerns" so you should be able to lititimatly change your Model (database, entity Framework, etc.) without updating your controllers or views.
That said your model's responsibillity is to return the data required by the controller/view. So it needs to be consistant. So if you model is bound to a view that return data x, if this view is updated, moved to a new platform, etc, etc then the model should still return the same basic information (for it to continue to work with your existing views/controllers).
If your using code first then you should be able to generate any required db views, etc. on a new db, providing this db supports code first generation (so basically MS-SQL I believe)
When using Editor- or DisplayFor you can pass in the entire model and it will show all the properties on the model.
When you start a new web application, which pattern are you choosing between MVC and MVP and why?
(This answer is specific to web applications. For regular GUIs, see What are MVP and MVC and what is the difference?.)
Traditional MVC for GUI applications
This isn't really relevant to web applications, but here's how MVC traditionally worked in GUI applications:
The model contained the business objects.
The controller responded to UI interactions, and forwarded them to the model.
The view "subscribed" to the model, and updated itself whenever the model changed.
With this approach, you can have (1) multiple ways to update a given piece of data, and (2) multiple ways to view the same data. But you don't have to let every controller know about every view, or vice versa—everybody can just talk to the model.
MVC on the server
Rails, Django and other server-side frameworks all tend to use a particular version of MVC.
The model provides approximately 1 class per database table, and contains most of the business logic.
The view contains the actual HTML for the site, and as little code as possible. Basically, it's just templates.
The controller responds to HTTP requests, processes parameters, looks up model objects, and passes values to the view.
This seems to work very well for server-based web applications, and I've been very happy with it.
MVP on the client
However, if most of your code is written in JavaScript and runs in the web browser, you'll find lots of people using MVP these days. In this case, the roles are a bit different:
The model still contains all the basic entities of your business domain.
The view is a layer of fairly dumb widgets with little logic.
The presenter installs event handlers on the view widgets, it responds to events and it updates the model. In the other direction, the presenter listens for changes to the model, and when those changes occur, it updates the view widgets. So the presenter is a bidirectional pipeline between the model and the view, which never interact directly.
This model is popular because you can easily remove the view layer and write unit tests against the presenter and model. It's also much better suited to interactive applications where everything is updated constantly, as opposed to server applications where you deal with discrete requests and responses.
Here's some background reading:
Martin Fowler's encyclopedic summary of MVC, MVP and related approaches. There's a lot of good history here.
Martin Fowler's description of "Passive View", a variation of MVP.
Google's MVP + event bus
This is a new approach, described in this video from the Google AdWords team. It's designed to work well with caching, offline HTML 5 applications, and sophisticated client-side toolkits like GWT. It's based on the following observations:
Anything might need to happen asynchronously, so design everything to be asynchronous from the very beginning.
Testing browser-based views is much slower than testing models and presenters.
Your real model data lives on the server, but you may have a local cache or an offline HTML 5 database.
In this approach:
The view is very dumb, and you can replace it with mock objects when running unit tests.
The model objects are just simple containers for data, with no real logic. You may have multiple model objects representing the same entity.
The presenter listens to events from the view. Whenever it needs to update or read from the model, it sends an asynchronous message to the server (or to a local caching service). The server responds by sending events to the "event bus". These events contain copies of the model objects. The event bus passes these events back to the various presenters, which update the attached views.
So this architecture is inherently asynchronous, it's easy to test, and it doesn't require major changes if you want to write an HTML 5 offline application. I haven't used it yet, but it's next on my list of things to try. :-)
Both MVP and MVC make sense and allow to separate logic from display.
I would choose MVC because it's widely used in web development these days (Rails, .NET MVC which is used for SO) so my application will be more easily maintainable by someone else. It is also -to me- cleaner (less "power" given to the view), but this is subjective.
Another alternative is MTV, Model-Template-View which Django uses.