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()
Related
I have a controller for my Portfolio, and the view model I am using is called DisplayItem. The function of the model is not relevant, but the models represent data about parts of my portfolio.
At the index page for this controller, the top 5 portfolio DisplayItems are built by pulling the required information from a database, and then a collection (List<>) is sent to the view. The view displays previews in a column with buttons to "view the project" for each project displayed. Clicking these buttons will route to the PortfolioController action "Display".
My question is about the efficiency of two methods of sending the appropriate data to the view for the action "Display". I can of course send the ID for the selected DisplayItem, and pull it from the database to rebuild the model and send it to the view. My initial thought was that this is unnecessary work for the database, seeing as I had previously pulled the required information. Though using the ID method would allow me to not pull the rest of the information until necessary.
My alternate idea is to serialize the model (it contains collections that can't be sent with POST), and then post what I need as a string to the action and then serialize into an object.
My experience is by and large not web, it is Game Programming, so I am out of my element to some degree and would love advice on which of the routes to opt for, or if there is some better way to do this.
I would prefer to query the database again whenever page loads. It allows to
-> check validation of input(id passed)
-> authorization of user for the requested info
-> decrease bandwidth(if data is large).
-> makes routing URL more user friendly(easy to bookmark).
As your application develops over time, your DisplayItem will have increasingly richer information pertaining to it, while your index view will only display summary information.
As the index view and the detail view will eventually require different sets of information, simply pass the ID field over the wire.
As Stepen Muecke says, reading from the database will be fast. Databases are good that way :-)
I have a controller with a get and post action, on the post it checks if the model state is valid. If it is valid the page process the data and redirect. If the model state is not valid it will return the view back with the model. To ensure the drop downs have data I need to repopulate the items from the database which means I need to make another call to the database.
Is there any way to cut the call out to the database by caching or any other method?
The problem is that the browser is only submitting the values for your drop downs and not the text. You could get around this by creating a hidden element which submits the text in addition to the values.
But is that a good idea? In my opinion, no. You're creating extra network traffic between browser and the server in order to save traffic between the server and the database. In most cases it will be more efficient to retrieve the data from the database than the client.
Also, the data may have changed between when you sent it to the client and when you send it back the second time.
Ryan has a good point. I'm assuming you're coming from a WebForms background where everything was cached in the view state and posted back to the server. Asp.net MVC by its very architectural lends itself to a different approach where it's standard to re-query the database for data presentation to the user i.e. dropdown list values.
So you should only post back to the server the values the user has input. This is happening via the view-model. I would make a common method which accepts your view model and does the standard database pull and map to model. This way you can use the same method for the initial Get request and also for validation failure post-backs.
Also, if we're talking about small data sets then I would most definitely re-query as it's not expensive to do. If the drop down lists are huge then it depends on the data itself. Does this data change infrequently? Then it might be feasible to cache it on the web-server in a static list. If it does change frequently then you could look into more advanced solutions like memcached or redis.
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 :)
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 was wondering if anyone knew of any way i can implement an application which will do the following.
Allow a user to specifiy a connection string to a sql db
Allow a user to specify a table in the db
Allow a user to specify columns from the specified table
Generate Views, a Controller with Crud methods, & Data access code on the fly for the specified table columns in a subdirectory on the current web app.
I'm aware that there are apps that currently do this (such as sharepoints list creation stuff), but i'd like to see how this was accomplished and recreate it for my own learning purposes.
Thanks alot for any help
Take a look at Microsoft's take on scaffolding, also, some time ago I was developing a taxonomy app and found this meta data model in codeproject
Edit: another cool SO link
Have you check out SharpArchitecture?
Anyway I fiddle with MVC 2 based AutoCrud when I'm not saving the world from aliens so I can give some pointers and point to things to check out:
Become familiar with how MVC 2 can auto scaffold up your edit screens
Understand that you'll have to pass "meta" information about your models somehow. In MVC 2, this is called ModelMetadata.
Tackle how to display related or associated models in aggregate root or parent screens
Learn how to generate code, and inspect ddl schema or meta information with T4 templates.
Thats all I can think off for now. This is not an easy task and a comprehensive answer is probably enough to fill a book.