Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm working on a project using MVC and Entity Framework. For now, what I am doing is that I am using the Controllers to directly do "TryUpdateModel" within their Action methods using the auto-generated Model by the Entity Framework.
My question would be, is this a good / recommended approach? Of course, the Model I am passing still to a repository class for further processing and saving.
I am curious. What if I create a "wrapper" model to the auto-generated one? Can the ViewModel be this "wrapper" model?
Your thoughts are good. It's better to use the wrapper model instead of the autogenerated one. Because autogenerated model have the role of DAO (Data Access Object) and sometimes don't fit with your needs for View Model.
The actual View Model should be the wrapper model. Because sometimes you only want a chunk of your DAOs (autogenerated model).
You should avoid directly updating the model or make sure you explicitly set which properties it's allowed to bind to. The reason is that the method you are using is opening up your code to vulnerability called overposting.
Overposting in short is that a hacker modifies the form to inject properties they are not supposed to be able to update. See here: http://odetocode.com/blogs/scott/archive/2012/03/11/complete-guide-to-mass-assignment-in-asp-net-mvc.aspx
Other than that it's a design desicion like any other. Both ways have some pros and cons. You get less code to write/maintain if you do it your way. But once you need to make changes you have less flexibility because the form and the model need to match, which is not always the best way to build the form.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
If I have a number of pages that all have 3 common fields, is it recommended to have a base view model class that contains these 3 fields, and then on the viewmodels for each page, inherit from this base class?
I read somewhere that this was bad practice, but I’m not sure why. As it’s removing duplication and the validation still works etc.
Thanks
Jenny
I would suggest using composition rather than inheritance. Put these 3 fields in a separate class and have a property of this class in each view model that needs them.
Composition tend to be a bit more flexible than inheritance. A typical example would be that you can only inherit from one class, but you can have as many properties as you would like.
In my opinion, this is bad practice as your project gets more complex you will need to make changes to your fields and one template you use as base class might contain different amount of fields than you needed initially.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm building a C# WPF app that will use IBM iSeries data for starters but will use oracle data via web service later. In order to switch between them (and support testing) we create interfaces and program the view to interface, right? Each of the data sources would be responsible for mapping to a common DTO structure used in the view model.
So if these two data sources that implement the interfaces are in separate projects, where are the interfaces defined? I'm thinking about how to define the interfaces so I don't have to keep up separate versions in the respective data source projects. If I create the interfaces in the view then it would create circular reference, the data source needing the view for the interfaces and the view needing the data source for dependency injection.
Please forgive me for the rather generic question. I'm not asking "how do I structure my app", it's more of how do I solve the specific issue of the mechanics of the interfaces.
Thanks, Mike
Put them in a separate project. Add a reference to that project wherever you want to use them.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am working on a asp.net mvc project. Also I want to use n-layer solution structure. So, I am using the following structure for my solution. It shows specially the part of the solution I have doubts with. I am planing to create interfaces for each entity I need in order to not repeating code and not have problems when passing data (lists or objects) from dal to presentation. What do you think? Is that a good approach?
[
I think you're missing the point of what MVC is. It effectively handles your layers. Using a BAL and DAL is N tier application. If you were using a real MVC project these layers are meaningless.
It's better to work with Generic repository pattern. LINK
You should create a Domain layer which will be the core of your project, in there you put your entities, your interfaces for entities, repositories and services, and this layer do not references any other layer. It makes your architecture more flexible, for example, if you work with NHibernate, but needs to change to EF, you just create a Class Library, and implements the repository interfaces that is in Domain layer, and the other layers not need any change.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In C# commonly use DTO classes for data transfer. But also we can transfer data using Entity Framework generated class. But most of the time we uses DTOs to transfer data. Why DTOs needs to pass data across layers instead of using Entity Framework generated classes.
I think one reason, using dto classes does not directly bind the client to your database model, as it would if you were transferring ef classes. It allows you to make changes to your backend and in some cases keep these changes from effecting your clients. There are truly many more reasons, I think doing some research on the net will help more perhaps, there are many fantastic articles. However you will have to decide whether the use of dto classes fit into your current project. Some people say dto classes are bad and they go in depth to explain why they say so, others say the opposite and again explain why they say so. You will need to determine which is best for the task at hand. Overall I think answers for this question would be opinion dependant. Personally, I love dto classes.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I am learning MVC. In this tutorial, entity framework is used form the 'model' part. I am used to OOP in programming. So, i would like to use custom objects instead of entity framework. Is it possible at all?
Sorry if this a foolish question.
an mvc action injects what it wants in a view.
return View("test");
A razor view can display whatever was injected in it.
<body>#Model</body>
Is it possible at all?
Of course, MVC is in no way bound to Entity Framework. It's even advisable to create your own ViewModels, instead of using entity classes for that.
Yes, you can use custom object as model but you need also a layer to access real data.
EF allows you to create model and provides a framework to access/modify data.