I'm new to MVC, I only done a basic tutorial with a standard application for editing an existing table, adding rows, view it, etc.
So there was a static view, static controller and a static model, which represented 1 table in the database.
Now I wonder how should that work, if I don't know yet, how the model is going to look like.
In my case, the client can first create a table, where he defines, which rows and what datatypes, etc. and then he can edit the table.
Is there a standard way for dynamic models, or is mvc the wrong way for this?
MVC works fine for this. With MVC, I just split each necessary bit of code up into the three categories. So try to think in an "MVC" Way.
The logic that is needed to connect to the database - Definitely a Model.
The displaying of the data in a structured table - Definitely a view.
The communication between the data gathered with the logic, and the displaying of that data - Definitely a controller
The idea of MVC is to separate the back end logic from the displaying of said logic. This helps to separate the two distinct parts of your project, and is generally considered good practice.
Hope this will help :)
Related
Problem:
If I have a scenario where I don't want to change my model properties and need to get one more attribute from some table, is it fine if I write a query inside a view and show the result?
If the answer is no, I would like to know why it's not considered a good way.
In my opinion you should never do that. Just because you loose the entire paradigm of the tool you are using.
In a few years, this is confusing to you, or someone else maintaining the code. If you don't want to change it all, use dynamic properties, ViewBag or other options to keep your flexibility, test-ability, etc.
Yes.
View is not a mirror of your data structure. Actually, often it's an
aggregation and/or manipulation for user-friendly presentation of the data that stands behind.
In my opinion, you should never do queries in your Views. It's called MVC and the proper way of using it is to separate concepts.
You should have a Model, a Controller, a View and a Repository (as the simpliest approach). As the name suggests, View must be used only for displaying processed data.
More information about MVC best practices is here.
I remember when I started working with MVC. I didn't know about this and my teamleader told me it's never a good choice to do this.
Conclusion:
It's just a matter of design and perspective. If you're doing a project for yourself or for the university, organize your code as you wish. If you're working in a professional environment you should respect some working principles
Another important factor to think of, is this: if another person must refactor or modify your code he must know where to find methods, where to find models and so on.
First of all, the reason why it's called MVC is because of the separation of concerns. View's are only concerned of the User-Interface. Queries are done on the controller. Another is it would be too confusing if you would place everything in a single page which already defeats the purpose of having MVC.
Though there are cases when querying the database from a View may seem easier and appropriate, you should be ready for the consequences of breaking separation of concerns (SoC). When you spread your DAL across many layers it's going to be hard to re-factor the database in the future. Another question is security - if you decide to implement database security or controller-based security later, your view-based queries will be a security point.
However, if the project is small, I would trade SoC for performance.
Most of (nearly all?) the examples I find on how to set up an ASP.NET MVC project are accessing the database context directly in the controller.
Like this for example:
public class MoviesController : Controller
{
private MovieDBContext db = new MovieDBContext();
//
// GET: /Movies/
public ViewResult Index()
{
return View(db.Movies.ToList());
}
I also know that there are a lot of controls (at least for the aspx view engine) that you can bind to a table in the database directly as a data source, so that it automatically displays the data.
To me this feels weird and I would like some kind of separation between the presentation layer and the database. Some kind of business layer and/or data layer that maps data from the database to view models, before using them in the view. Is it just me or are the examples all like this because it's easier to do? Is there some great gain that I'm missing? I guess it's a bit faster, but it just feels like I shouldn't use the same models in my database as in my views. I finally found an example that feels more right, where the database models are separated from the view models. But it's one example of a hundred.
What are your thoughts on this?
I understand your concerns as I have the same. It's really a pity that most of the examples out there are not using view models. Because of this people are struggling a lot when they start implementing a real application that differs from the most trivial examples seen in those articles.
As far as directly accessing the database from the controller, I don't think that this is such a big concern. You really don't need to implement lots of layers of abstraction if you don't need them and if they don't bring any additional value to your application. Jimmy Bogard wrote an excellent blog post on the subject of limiting your abstractions.
Most MVC tutorials teach you how to do it simply because it can be done, and that the explanation of the Controller usually comes before explaining the Model.
Take the Movie App tutorial for example - http://www.asp.net/mvc/tutorials/getting-started-with-aspnet-mvc3/cs/intro-to-aspnet-mvc-3
The majority of these tutorials first teach you how to display data using on the view, then using the controller to display in the view, then entering the data into the model and directing to the view via. the controller.
It's to keep the examples simple and focussed on the subject at hand.
I am working on my first ASP.Net MVC Application . I am using Razor view and MVC version is 3.
I am getting data for my model from the database in some raw format. Then i do some processing on it like concating strings, format date columns using some linq queries. Everything on the data that i already have in the model class.
I wonder all this code execution is happening on server. I want to move this burden from my server to client machines, i want to pass this raw data to my view and then write code in view to do this loop things and formatting etc.
I just want to confirm if this is a good approach to move on and if this really release some burden from my server.
Thanks
C# or VB that is written in your view is not client side. It's still server side. It's used to manipulate the rendering of the HTML before being passed to the client.
You'd have to pass all your raw data then process it with JavaScript.
Performance of your app would depend on each client machine and therefore not be consistent between 2 users. Maintenance would be tricky as a result.
To cut a long story short I would not recommend it. Your server is most likely designed to handle load. It's the right place for this sort of thing.
And I'd also read up on server / client side code execution relations. Simply doing MVC is a good start. It naturally teaches you how the web works more so than using web forms.
This may be pre-mature optimization. I doubt whether a server would be bogged down performing simple things like string concatenation, formatting, etc.
I suggest you only focus on this if you run into performance issues; else it isn't worth the effort.
I think you confused a View in MVC with browser HTML. You can have any C# code in View but not in browser. If you question is about doing business logic in View is then, read further.
MVC allows to plug any kind of view (mobile,desktop,web apps) to a controller. So view should not do any business logic else you will end up duplicating the business logic.
This LINK will help your understanding of MVC.
Data formatting in view not at all an issue but when you start implementing business logic in view that is the issue (I guess that's what you meant by use of linq in a View).
For instance inside a View, using linq on Model entities to loop through a collection and create a HTML table is perfectly all right, infact ViewModel should be tightly coupled to View.
[Trying hard not to be philosophical here but :)] In the end whatever architecture you use DO NOT limit yourself from thinking out of the box. Almost all projects use multiple patterns and most (good) developers solve business problems by unknowingly implementing a pattern. :)
I am quite new to ASP.NET MVC and MVC in general. Moving from the old school "spaghetti" design practices to WebForms was a big change, but this seems bigger (but better) in my mind.
I have some questions regarding data specific tasks.
For the sake of simplicity, say I have a database table called PIN with the column structure of PinId INT, Value VARCHAR(50) and another table called Entry with the columns EntryId INT, PinId INT.
I have an MVC view that takes in a string value as a PIN code.
The goal is to insert a row into the Entry table. To do this, I must lookup the corresponding PinId to the provided Value.
My question would be, where do I perform this lookup of data. I can easily do it in the controller where I am performing the insert of a new Entry object but is that right? Should this lookup be performed in the Model somehow?
In addition, I am following the instructions and practices outlined in WROX's Professional ASP.NET MVC 1.0. I have created a DataRepository class which handle all of my DB heavy lifting, and am utilizing the validation class as described in that book.
Any insights would be welcomed as I am a true newbie to MVC.
Cheers and thanks stackers!
Take a look at ModelBinders. This allows you to define how bind inputs from the data you are sending to your action to your Model objects. Your Action can also just take an argument of the type you want to save, and in your ModelBinder, you can do some lookup against the repository, etc.
There are many good blog posts on this if you do a search, now that you know to look at ModelBinder. Scott Hanselman has a good basic one:
http://www.hanselman.com/blog/IPrincipalUserModelBinderInASPNETMVCForEasierTesting.aspx
Never place search, add, update, delete code within a controller. Actually, there should be next to no code in the controller.
In the MVC world the controller is simply a means of getting a model from the view to your business layer and vice-versa. The aim is to have as little code here as is possible.
If you can use Linq2SQl then this would be a great place to put the entities. You can then use your data repository to do not only the heavy lifting, as you put it, but also all the other little things.
Linq2SQL will create a partial class. So, you could create another partial class which will do the CRUD and search work for you.
I have a data input module where I add the information of my product and its sub information like:
product basic info
product price info
product price details
price info and price details are related to product and are lists
In my web forms approach I would store my main product object on the view state and I would populate it's pricing info and details while doing ajax postbacks. This way I can create a compact module that is very user friendly in terms of defining a lot of data from one place without the need to enter these data from seperate modules. And when I am done I would do one product.save() and that would persist all the data to the respective tables on db.
Now I am building similar app on .net mvc framework and pondering on what would be the good way of handling this on mvc.
I don't resonate towards storing all this on client side till I click save. And saving to the db after each action makes me remember the days I was coding on asp.
Will appreciate your inputs on ways to approach this on mvc framework
I believe the best way of doing this is storing the data on the client side. It reduces unnecessary postbacks and improves responsiveness of your application. If you really want to store it on the server, you can use SessionState.
If you really want to store it in something like ViewState, you can go with a solution like this: ASP.NET MVC - Is there a way to simulate a ViewState?. However, I recommend against it as it will make things more complicated. Doing it client-side is probably the most elegant way and storing it in SessionState is the easiest.
Remember that you can always escape the MVC pattern and use a simple Web form for that specific page (which will give you ViewState where you need it): ASP.NET MVC controller actions design
store your Product list to the Model of the view and each time you change a value you can do a Ajax post to the controller and save the changes to the db, use partial views to display each item in your product list
you can try to integrate http://www.castleproject.org/ActiveRecord/ for easy saving and updating. That way you can just map your Model on your database using ORM(Object Relational Mapping). It takes a bit more work in the beginning but you will end up with simple commands like product.Update() and product.Create()