So I am making a registration page in ASP.NET MVC and theres a list of fields which changes depending on a number of conditions (taken from a database).
What would be considered the best approach for displaying these fields on a view without code changes each time the DB is updated.
The current system I am thinking about is making a Dictionary with "Name, DataType" then just iterating through the list and putting a new input type of each name (using a switch for data type to get the correct editor). But it seems like a old fashioned and not fully utilizing the benefits of the .NET MVC system (such as validation, default values, customized editors for specific content).
Is there a approach I may possibly be not aware of in .NET to handle this problem?
I had very similar problem. Posting is here.
No, there is no polymorphism views in ASP.NET MVC. At least I couldn't make it work doing tons and tons of experimentation and asking this question several times in different ways on Stack Overflow.
The type of #model defined in the view will define its type inside the view, rather than actual type of the model (in case it was interface or abstract class or base class, while you passing in child class with all your beautiful decorations, which won't work, since type is defined by model type).
Sorry, no positive answer to your question. I ended up writing bunch of editor templates, which were only different by model type inside. Huge DRY violation, but this is the way ASP MVC worked, unfortunately.
Hope this helps saving you some time.
Related
This question already has answers here:
Why do we use ViewModels?
(4 answers)
Closed 5 years ago.
I am building a web application with ASP.NET MVC and am still a beginner with this technology.
I have learned that it is best practice to have a ViewModel for each View. I can understand why this is a good idea. However, in my situation it seems to create a lot of extra work.
I have a model called Rule.
It contains an Id, Title, Description, LastModifiedDate, CreatedDate, among other fields.
I have an Edit, Create and Details view for the Rule model.
According to the best practice, I have to make a ViewModel for each of the above Views. But the ViewModels for above Views are nearly identical. One of the only differences is that the Create-ViewModel has no Id, but the Details and Edit ViewModels do. Other than that, the ViewModels are nearly identical. That is, they contain the same attributes and same DataAnnotation validation fields.
Why do I think this is troublesome? Suppose I want to change some of the Data Annotations. E.g. chaneg a Maximum Length of a string attribute. If I wish to do so, I have to do so in both the Rule model, the Create ViewModel and Edit ViewModel. And likewise if I wish to add new attributes, I must do so in all the models.
Am I doing this right, or can it be simplified?
Well this is more an implementation decision rather than a best practice rule. You have to take in consideration some of the pros and cons:
Different ViewModel for each view
Modify only the ViewModel associated with the view
Flexibility
Hard to maintain with very large applications
Reuse ViewModels for different views
Modify all the ViewModels at once
Much easier to maintain
Limited flexibility
My advice would be to create the base RuleViewModel without the ID property and for the edit and details actions inherit the model and add the additional column.
It is/was never a rule to make ViewModel per View. It is all about how your architecture is. As per your requirement if you feel both the views are exact same then use same ViewModel.
IMO do not use data annotation, if possible go for Fluent Api.
For all operations: add, update, remove - you can use one view model - Rule. It is completely fine as you want to manipulate with this single object, right?
The only difference would be the displaying of multiple Rule objects - list view page, here you might want to create an extra viewmodel like RuleListViewModel which will contain a collection (IEnumerable<Rule>) of objects and maybe some more properties for filtering and so on.
It sounds like you are mixing your view models and business objects. I usually try to keep these separate as they serve different purposes.
Your business object can have CRUD methods. Your view model can have a property that exposes your object, and can in fact expose other objects if required.
Doing it this way preserves the single use rule and makes it very maintainable.
But, this really is a design choice rather than "best practice" which (let's be honest) changes with the wind.
Hi I am new to MVC and I have to create a dashboard page in my applications which has 4 different zones having data related to different models. And i have to make my view strongly typed view. Though I accomplished the task using Tuple in my view.
#model Tuple<ModelFirst, ModelSecond, ModelThird, ModelFourth>
The question is which is a better way using Tuple or creating a ViewModel having only the desired properties. I have to keep in mind both the performance and number of Lines of codes.
Usually view models have metadata associated with them which among other allows you to perform validation and integrates with editor/display templates. Tuples don't seem appropriate. Another disadvantage is that they express less clearly the purpose of each property in the view model (Model.Item1.x, Model.Item2.x, ..., no-one else than the original developer can make any sense of this, and if he is like me after few days even he won't be able to make sense).
quotation from #Darin Dimitrov
i'm building a form managment system, thats is, the system will contain many forms, will save them, and perform logic on them, I want to do it using the DDD approach.
I want to support easy form layout later on using ASP.NET MVC, so far i see the domain like this:
I'll have a base form entity, which should(for now) have a name, fields(and theire values) and validation logic.
My questions are:
How should i write the field valueobject using generics? i cant seem to figure it out..
Should i encapsulate the validation logic inside the form or do it using the specification pattern?
How should i write the field valueobject using generics? i cant seem to figure it out.
Too vague question. Specify your context a bit - what kind of value objects you are trying to define, why exactly you need generics etc.
Should i encapsulate the validation logic inside the form or do it using the specification pattern?
Validation logic goes where it has to go. Domain validation logic should be encapsulated in specs, but that's not mandatory. Main thing - you should be able to figure out and understand applied validation when looking at source code of domain object class definition.
Apart from your vague descriptions, dealing with forms is a problem that is inherently not well suited to DDD. What kind of an object model can you build from a flat list of options?
Of course you will need validation logic that is specific to the form in use, but simple OO Design will get you far enough here, I don't see where DDD will buy you something.
As a side note, check out Document Databases, they might be better suited for your task than a sophisticated domain model stored in an ObjectDb or a relational database.
I have several Rescues defined for possible faults, however I am unable to access the ViewData to populate it with things we need the masterpage requires to render. Is this hidden away in a controller we can utilize?
Sounds like you need ViewData to be made available in the masterpages... I think that will be a problem since not all the controllers put/assure that data is there. I'm pretty sure you'd have to have some type of custom controller base to ensure consistent data in all of your controllers. Try looking into this.
I might be wrong but I have seen this question brought up a few times before.
I am working on a Windows Forms app for quite some time now, and I really find myself doing more typecasts in the GUI code than I ever did in my underlying business code.
What I mean becomes apparent if you watch the ComboBox control that accepts some vague "object" as it's item.
Then you go off and may display some DisplayMember and a ValueMember and so on.
If I want to retrieve that value later I need to typecast my object back to what it was. Like with strings getting the value takes
string value = (string)combobox1.SelectedItem;
Since there are generics in the Framework for quite some time now, I still wonder why in the Hell not one control from the standard toolbox is generic.
I also find myself using the .Tag property on ListViewItems all the time to keep the displayed domain object. But everytime I need to access that object I then need another typecast.
Why cant I just create a ComboBox or ListView with items of type ListViewItem
Am I missing something here or is this just another example of not perfectly well thought through controls?
While the criticism of "didn't use generics" can't be fairly applied to controls developed before their existence... one must wonder about WPF controls (new in .NET 3.0, after generics in .NET 2.0).
I checked out the AddChild method in ComboBox. It takes an object parameter (ugh).
This control is intended to be used primarily via XAML. Was this done this way because there is no way to specify a type parameter in XAML? (aside, is there no way to specify a type parameter in XAML?)
Sorry to have no definitive "Why" answer, just sharing the common misery of needing to cast when working with the UI.
I dont think you're missing anything.
It's just that these classes were created back in the pre-Generics days, and WinForms is simply not cutting edge enough for MS to spend a lot of time changing or extending the API.
I often create wrapper classes for controls. This allows me to use generics. This is often in conjunction with Reflection, which is not type safe at compile time, but can be at run time.
A common source of this problem, I think, is not separating your view/presentation logic from your in-memory data model logic. Which, unfortunately, is an architecture fault that WinForms and the Visual Studio GUI designer are complicit in.
WinForms and the VS designer do not encourage the programmer to separate the management of their data objects from the form classes themselves. It would probably be better if the ComboBox ListViewItem objects didn't offer any support for arbitrary objects, either via generics or Object collections..
Unless you are hacking together something of limited use and lifetime, you should try to avoid storing references to individual data objects right in your controls or forms. They should be managed separately, and if they need to be referenced, it should be done via a model management class designed for the particular type of view class you're working with.
A simple-ish bandage for the problem, though, might be to "map" the text representations that you place into the ComboBox or ListView to the original objects, using a Dictionary field member on your Form class. It's not an ideal solution, but gives you at least a half-step of indirection between your data and your UI controls, which can make your code easier to maintain.
Edit: This is admittedly separate from the ListViewItemCollection class exposing Object instances... The official defense is likely to be that they wanted to support the standard IEnumerable and ICollection interfaces. But there's no reason they couldn't have also provided type-specific overrides of these methods, since it is designed explicitly to store ListViewItem instances. So I have no answer for you on that particular question.
Well, if you data-bind your controls to a DataBindingSource, you can get at your data that way, but AFAIK that's still not strongly typed. If you are displaying multiple parameters/aspects of a single business object, you can bind to that, then access the (strongly typed) members instead -- of course, this all goes back to Turbulent Intellect's answer, which is better separation between model and view. Still, I agree that generic-based typing would help.
It is possible (you can make your own generic controls, if you wish), but the form designer that comes with Visual Studio will freak out if you do this. You'll have to do stuff without it.
You aren't the first one to think of this, and Microsoft has already received a fair share of criticism from the public for this. Let's hope they add support for this in the future.