I am creating an mvc project, for simplification i have two entitys: Movies and MoviesGenre.
I want to display a list of genres and the amount of movies each of them contains.
Now i have a problem with the design. I am not sure who is responsible for it. I solved that by creating a method in MovieController that returns the amount of movies by genre id and created a method on the MoviesGenreController that select all the genres and uses the MovieController(By instantiating an object) method to get their count.
That doesn't seems like good design to me. Which controller is responsible for this? Do I maybe need to create an extra controller for this logic? Thanks.
You need a data layer project which will manage the access of each controller to the underlying database.
I would suggest the following design:
create a library project (DataLayer) project which connects to the database.
Potential methods exposed:
List GetAllGenres();
List GetMoviesByGenre()
You can either inject the DataLayer as a service or just simply allocate a new object in each controller ctor. This is more like a personal preference... The DI approach is more flexible a more in line with the DotNetCore architecture.
Both MovieController and MovieGenreController should use the methods from the DataLayer.
Related
I'm trying to come up with a reusable pattern for updating MongoDB Documents when using Spring Data in conjunction with Spring MVC.
The use case can generally be summarized by:
A document is created in Mongo using repository.save()
Parts of that document are then presented in a Spring MVC editable form.
A user submits updated parts of that document which are then saved.
If I use the repository.save() method in step 3, I will lose any data in the document that was not bound to the form. Making the form responsible for the entire document is fragile so this is where it seems the findAndModify() method of the MongoTemplate comes in handy.
To use the findAndModify() method, I've created Form objects that support a toMap() method which takes the Form object's properties as a Map and removes some of the fields (e.g. class and id). This gets me a Map that contains only the fields that I care about from the Form object. Passing the object ID and this map to an update() method on my customized repository, I build Query and Update objects that I can pass to the findAndModify() method.
Using this approach, I'm able to add fields to my objects easily and only worry about instances when there are fields I don't want to update from a form posting. Document fields not manipulated by the Form should be retained. It still seems slightly convoluted to be using both the Repository and MongoTemplate so I'm wondering if there are better examples for how to handle this. It seems like this should be a consistent pattern when working with Mongo and Spring MVC (at the least).
I've created a sample project showing how I achieve this model on GitHub. The Spock Tests show how "updating" a Document using save() will blow away fields as expected and my update() method.
https://github.com/watchwithmike/diner-data
What are other people doing when dealing with partial updates to Documents using Spring MVC and Spring Data?
If you are taking whatever the user supplies and just shoving that in the database you are running the risk of doing something dangerous like updating or creating data that they shouldn't be able to. Instead, you should first query Mongo to get the most recent version of the document, change any fields (it looks like you are using Groovy so you could loop through all the properties and set them on the new document), and then save the new, complete document.
If you are making small, consistent updates (like increasing the number of votes, or something like that), you could create a custom MongoDB query using the MongoTemplate to do an update to a few fields. Check out the spring-data-mongodb docs for more. You can also add custom methods to the MongoRepository that use the MongoTemplate.
I have a 3-tier web application wit ha bunch of simple forms. One to list records, one to edit a single record, etc. The works.
I have a DataLayer where my EDMX is.
I have an App Layer where my POCOs are.
I haev a BusinessLayer with all my controller classes, etc. (not MVC!)
I have a UI layer where my web UI is.
The EDMX has many, many tables wit ha lot of navigation properties.
Of course, when I fetch the data in one of my controllers, e.g. GetCustomerById(int id), I create the Object context and close it when I'm done.
However, the ObjectContext is out of scope when I try to access the navigation properties in the UI layer.
Should I do (using MyContext = new MyContext()) {... } in the web layer?? that does not seem right.
Should I create another set of POCOs that I populate from the entities' data from the BizLayer?
What happens when I want to save data entered in a web form? Would I call a BizLayer controller e.g. SaveCustomer()?
My question is, how do you design the web UI layer if I want to be able to properly access the navigation properties of an entity?
Note:
EDMX is set to LazyLoading.
You want to use lazy loading in UI but it means that UI defines lifetime of your ObjectContext. There are many ways to achieve this without exposing the context to UI. You can for example use this simple approach:
You mentioned some controller which uses context and disposes it. So make your controller disposable and instead of disposing context in every method use single context for whole lifetime of the controller. Dispose the context in controller's Dispose method.
Instantiate your controller per request. So for example you can create instance of controller in Page.Load and dispose it in Page.Unload.
Use your controller and entities as you want. Whole processing of the request (between Load and Unload) will be in scope of single living context.
Anyway you should not need lazy loading in Web application too much. In your form you usually know exactly what entities you need so you should request them directly with eager loading.
Going through the Symblog tutorial of Symfony2, While creating forms I came to a point where in I create Contact Entity (Entity/Enquiry.php) where I define some fields and some methods to access these fields. Then I create another folder Form/EnquiryType.php to build the form and then a contact.html.twig to display. I am unable to understand why we created 2 namespaces for Entity/Enquiry.php and Form/EnquiryType.php. when they have to deal with each other. Why dont we wrote both the classes within one folder or one file. And one more question. Do they belong to Controller or View part of MVC.
Form types are here to configure how data coming from objects (like Entities) are mapped to a form (and vice/versa).
Entities should'nt be named "entities", they should be just your buisness objects, that can be persisted through a layer called doctrine2.
To answer you on separation of concerns,
Entities are about M,
while form Types are about user inputs (so the VC).
View because it render a human interface to let user enter input,
Controller because that's where you handle the form lifecycle.
The reason is logical separation. Why don't we define all parts of MVC in one folder/namespace? Because it will be a mess. That's why logical separation is needed.
And not all entities have to have related form types — using entities without forms is normal.
I have been reading about "Fat Controllers" but most of the articles out there focus on pulling the service/repository layer logic out of the controller. However, I have run into a different situation and am wondering if anyone has any ideas for improvement.
I have a controller with too many actions and am wondering how I can break this down into many controllers with fewer actions. All these actions are responsible for inserting/updating/removing objects that all belong to the same aggregate. So I'm not quiet keen in having a seperate controller for each class that belongs to this aggregate...
To give you more details, this controller is used in a tabbed page. Each tab represents a portion of the data for editing and all the domain model objects used here belong to the same aggregate.
Any advice?
Cheers,
Mosh
For all your tabs you can use one action, that have an tab parameter, that indicate what data you need to return.
The controller job is to cast this string tab into enum type variable. Then the tab will be send to the repository, and the repository job is to return data in response to the tab value.
The controller should do its job through to services: Input Validator and Mapper.
The mapper service job is to map the user input (typically strings) into actual typed value (int, System.DateTime, enum types, etc).
The validator job is to check that the input is valid.
Following this principles should keep your controllers really tiny.
If you wanted something simple and easy I'd suggest just splitting up the controller into partial classes based on the tabs. Of course, it's still a fat controller there's just some obvious separation between the various tab functionalities.
I'm looking for some advice on storing views in a data-store (database, file, other) and display them based on routing data, all using ASP.NET MVC 2 and ASP.NET Routing.
For example, I'd like to be able to display different views based on the following route data:
/{country}/
/{country}/{area}
But in the same vein I'd like to display:
/{planet}/
/{planet}/{satellite}
All are based on strings, and the data isn't fixed. So based on the number of segments maybe, use that as the selection criteria into the data-store...additionally, I may not know the segments up front, so they'd all be dynamic.
I'm was hoping we could get a few different methods together here, as kind of a reference for all - I'm sure some methods won't suite everyone...
So, how would you do it?
Branislav Abadjimarinov suggested a Controller Factory which could be used to do the look-up and display the page dynamically. I like this idea, what do you think?
There is no way for MVC to understand from this url's which route to choose. You have to make the routes more specific. For example:
/planet/{planet}/{satelite}
/country/{country}/{area}
You also have the option to define your own controller factory. The controller factory decides which controller to instantiate based on the route. So you can put some custom logic in it like - check if the {planet} parameter exist and if yes instantiate Planet controller else instantiate Countries controller.
This Post could be really helpful for you.
Remember you always can add a new routing rule : )
Just like this