I have one model with a lot of attributes and one controller, but I also have nearly 100 templates. Approximately 90% of fields and view in this templates are the same. User can fill any template, save it and ,as needed, print it as PDF. What is the best approach of implementing this kind of relation?
I see only one way:
1. 1 model, 100 controllers(because all templates have to have all REST actions) and included module with same actions for all, and 100 shared partials for form and view.
Ideally, of course, 1 model, 1 controller per template, but it is not the DRY'st way.
Am I wrong? And there is another simple way with one model, one controller and 100 partials?
Will be appreciate for any advice.
This is a solution that could be implemented provided your scenario is simple. (I am giving this because you have not mentioned anything about the so called templates and types of fields).
Anyway, have one controller and one model (Because you say 90% fields are same. Having 10% nulls aint a big deal). Then create a form with all these fields organized as templates. Have a select box to select the template and based on that hide or show your fields with JavaScript.
Assuming you have a field to indicate template_type in your model you wont be having any problem saving this and displaying. Or even switching templates by editing your model.
Related
I have a view for creating an entity by filling a form. That form contains several inputs and 2 datatables table. i write a considerable amount of JavaScript code for initialization and validation of the inputs. For editing the entity, i need the 95% of inputs and JavaScript codes.
First, I tried to move the common codes to a partial view but some of them worked and some of it didn't work. For example the tables not initialized.
As a second approach, I can also write a lot of if-else to check the current page (between Create and Edit) and do proper action.
How can i have two views and common codes in both? Is there a better or functional approach?
save your javascript code as js file. Drag and drop its link where you want to use it :)
You can use the same view for Create and edit functionality.
And regarding the inputs, you can take one property in the model which will indicate whether to show or not to show that input on UI.
Model:
For eg. Public string displayInput=[none/block]
view:
You need to set the value of displayInput field properly when you want to show all fields and when you want to hide some fields.
I have a Course Model which goes the controller and views in a restful way.
For my Course show, it is fully featured. I now want another Course show which will have a simplify page and it like to the original course show.
How can I implement this? I want it to be restful, so in my controller there should only be show, update, index, etc.
Should I create another controller that have an different name from the Model? E.g. Course2?
If it is an admin view vs. public view, I would have entirely different namespaces for two different RESTful controllers. Or if you think you're going have this summary vs. full view thing a lot, create namespaces based on that distinction.
Another option is to encoded the differences in a single ERB template. Or you could actually have the show action render different templates from the same action using some conditional logic.
Without more context though, I can't really say what's the best option. I am personally against creating non-RESTful actions unless it's really going to be a one-off thing. Non-RESTful actions tend to get out of hand in my experience and controllers can get really ugly and unintuitive.
If this is truly just displaying a subset or a different arrangement of the same information, then I think this is a job for the view. At most the controller can use the same action, but select a different view to render, such as might be done if the user wanted to see html vs plain text.
The controllers job is to interpret the model and the views job is to collect and display information. I think you would be concerned about the view having logic in it if you what you describe as a "summary" were more than just a subset of the info, for example if you started to calculate the distances being traveled or how long it would take or how much it would cost based on the data that is provided, then that would be bad.
So I this is just a subset, then I would suggest either rendering partials based on some variable set by your controller, or if organization of the display needs to be substantially difference, then the controller can select a different template to render.
I have read online that it is bad practice to use a "kitchen sink" model:
Rule #3 – The View dictates the design of the ViewModel. Only what is
required to render a View is passed in with the ViewModel.
If a Customer object has fifty properties, but one component only
shows their name, then we create a custom ViewModel type with only
those two properties.
Jimmy Bogard's subsequent explanation of how this is good, however, left me a little questioning. It'd be so easy to have my Model just contain a list of Customers, I could even use my POCO's.
So now I get to create custom little view model fragments for every page on the site? Every page that uses a Customer property would get one, but of course could not be shared since some of the information is extraneous, if one page used Age but not Name, for example. Two new mini view model classes right?
This is very time consuming, and seems like it'll lead to a million little custom view models - can someone elaborate as to the utility of this approach and why the easier approach is bad?
View model class can be used not only to transfer values, but it also defines data types (data annotations), validation rules and relations different then ones used in model. Some advantages that come to my mind right now:
There are different validation rules when you change user's password,
change his basic data or his subscription setting. It can be
complicated to define all these rules in one model class. It looks
much better and cleaner when different view models are used.
Using view model can also give you performance advantages. If you
want to display user list, you can define view model with id and name
only and use index to retrieve it from database. If you retrieved
whole objects and pass it to view, you transfer more data from
database than you need to.
You can define display, and editor templates for view models and reuse them on different pages using html helpers. It looks much worse, when you define templates for model POCOs.
If you would use your POCO objects as view models, you would essentially be showing your private objects and break the encapsulation. This in turn would make your model hard to change without altering the corresponding views.
Your data objects may contain details that are appropriate only to the data access layer. If you expose those things to the view, someone might alter those values that you did not expect to be altered and cause bugs.
Many of the same reasons as for having private members in OO languages apply to this reasoning. That being said, it's still very often broken because it's a lot of extra work to create all these "throw-away" models that only gets used once. There exists frameworks for creating these sorts of models, though the name eludes me, that can tie objects together and pick out the interesting properties only which takes away some of the drudgery from creating specific view models.
Your View Model tells the View how data should be shown. It expresses the model. I don't think its necessary to have two view models unless you have two ways to express your model. Just because you have two pages, doesn't mean you will be showing the data any different way, so I wouldn't waste time making two mini View Models when it can be in one reusable view model, Imagine if later you have a page that needs Name and Age, you would create another view model? It's absolutely silly. However, if you had two pages both showing 'Age' and it needed to be shown in a different way, then I would create another one.
As an exercise in learning .NET, I'm moving some simple forms over into MVC, and have run into an issue. The form in question is a multi-part form that has option sections. For example, Section 0 is static and contains information like username, real name, email address. After that is a radio button with several options. If you click the first radio, it displays Section 1. If you choose the second, it displays Section 2, and so on.
In WebForms this was no biggy, as I just validated on postback and said if Radio1.Selected validate this, if Radio2.Selected validate that, etc. So now I've got a strongly-typed view with [Required] members, which obviously isn't going to work - I can't require members that aren't always going to be required.
With that said, is this the correct approach to the problem:
Create the members that belong in Section 0 in my strongly-typed view model class.
Create references to each partial's strongly-typed class in my view model class.
Create the partial views and then render them in the main view.
Depending on which radio button is selected, render the appropriate partial view.
Validate the model like usual...which hopefully will cascade to the partial models.
Does this make sense, or is the approach wrong?
That's a typical scenario where you need conditional validation, i.e. if some value is set then validate that some other value is required. Achieving this with static data annotations which are simple attributes baked at compile time can quickly turn into a nightmare due to their declarative nature. Well, you could always roll your own custom validation attributes but the problem with attributes is that you will have to specify property names as strings as they need to be known at compile time.
That's one of the reasons why I use FluentValidation.NET. Not only that validation rules are separate from the view models and that it integrates really nicely with ASP.NET MVC but handling scenarios like this would be very easy. You could have a sub-view model containing all the properties of the sub-section and then conditionally include it based on the value of a given property on the main view model inside its validator.
At top there is some most useful info about foo.
Between horizontal lines there is some immediate actions, if they are available, to perform on/with foo.
And below is thing that bothers me. There goes tabbed, detailed information about foo.
Those tabs can hold some actions too and can be quite sovereign.
So the question is - how to properly structure this thing (what should be controllers, actions, how do they talk to each other) in order to avoid unnecessary hussle?
I'm confused cause those tabs below are like a separate island.
In model - there's that strange thing: 1 on 1 relation. It's like there's a Contest (Foo), and Participant. Tabs are detailed description of Participant.
Currently I've modeled them both as aggregate roots. But it might be a wrong choice.
So - if there are two roots, it seems natural if both of them got controllers and Contest isn't really responsible to hold all data.
It seems that sub actions would be the way to go, but I foresee some complexity. When tabs will hold some actions, they will need to know how to redirect back to Contest details and how to pass info how to render correct tab. This coupling I would like to avoid but it seems there's no way to do that.
I can think of a couple options for those tabs ... which one makes sense probably depends on what your Model looks like, how you retrieve data and, to some degree, what the rest of your app looks like.
Option 1. Partial Views with RenderPartial(). Each tab is a partial view that renders some portion of your Model. For example, you would have a FinancialInformation.aspx partial view that renders Model.FinancialInformation.
Option 2a. Sub Actions with RenderAction(). Similar to above except that each tab is responsible for pulling its own data by calling an action method either on the same controller or more likely another controller that specializes in that information.
Option 2b. Same as 2a except that the tabs are rendered on demand using AJAX.
I should point out that none of these options is mutually exclusive. You might use option 1 (RenderPartial()) for the first two tabs since that data is inherently part of your model. And you might use option 2 (RenderAction()) for the other two tabs because, for example, you might have a ChartController the specializes in rendering charts ...