I am working on a business application which is being developed from scratch. We have opted to design our business logic using Entity Framework, and since the application has to be delivered on the Web we have selected MVC 3 (Razor) for presentation.
Things are pretty fine yet, but I am afraid how will I manage if anytime in the future we need to change our Entity Classes (like adding/removing fields in the business entities or adding more relational entities etc.). I know I can update my model by selecting "Update Model from Database" in Visual Studio (we are using Database first approach). In this case will I have to scrap my old views and generate new ones or is there any way I can update my exiting views.
That questions a little ambigous, so I'll talk about MVC concepts
The whole approach of MVC is "serperation of concerns" so you should be able to lititimatly change your Model (database, entity Framework, etc.) without updating your controllers or views.
That said your model's responsibillity is to return the data required by the controller/view. So it needs to be consistant. So if you model is bound to a view that return data x, if this view is updated, moved to a new platform, etc, etc then the model should still return the same basic information (for it to continue to work with your existing views/controllers).
If your using code first then you should be able to generate any required db views, etc. on a new db, providing this db supports code first generation (so basically MS-SQL I believe)
When using Editor- or DisplayFor you can pass in the entire model and it will show all the properties on the model.
Related
I am using the mvc5 database first approach on a project.
The project is huge, 170 tables or so in the database.
I was wondering, is there a way to automate the scaffolding of the "MVC 5 Controller with views, using entity Framework" per model?
I am pointing to my own Templates (Create.cs.t4, Delete.cs.t4, Details.cs.t4, Edit.cs.t4) and will be changing them quite often
Obviously going through each item to create the "new scaffolding" will take me hours so i was wondering if there is a way to automate this process?
Is there a command i can call to create all the controller and view scaffolding for all the models i have?
As of right now, there is no out-of-the-box solution to automating the scaffolding like you can create a data model for the whole db at once. This would be a good enhancement request to put in, though. Roll up your sleeves or hire a couple of interns.
So the way I've always worked with MVC in .Net is to create ViewModels for each View.
Now, with using Knockout, would I create my ViewModels in javascript instead of a C# class? And then have my main Model(in this case, EF generated Models) as my only C# Model classes? Or would I still go about create a C# ViewModel class along with my Knockout ViewModel?
I'm trying to set this project up DRYly, but I'm not sure of best practices in this situation.
You can create viewmodels (VMs) for the C# server side and still have them intended for the ASP.NET MVC Views. Then create VMs for the client side javascript views too. But the way I;ve liked it best is to use the MVC Views as the basis for the page, and have the Models be the basis for the JavaScript models. The only VM would then be the JavaScript VM since most of the presentation is really done client side. In other words, do the more static plumbing in MVC, then do the dynamic interaction client side.
If you are building primarily using client side JS libraries like KO I would not start with a VM for the MVC side unless you have a strong reason for it.
If you have specific questions, I'd be happy to try to help.
Create view models as you always do.
Create a HTML helper which generates a KO view model from it.
You should base your Knockout viewmodel on the view data from the server in order to at least have it initialized with data from the server without having to make a separate request to get that data.
You can optionally use the mapping plugin to map the view data to your viewmodel.
I have been tasked with coming up with an architecture for a medium to large company that wants to switch to MVC for their application design. A brief rundown of their current architecture:
90+ Web Applications created in Web Forms with an MVC type architecture, but not very functional. Basically a model stuffed full of anything you can think of and persisted to Session... Messy!
A Business Object Framework that started from CSLA.net, but has been modified so heavily you can't really call it that any longer. Lots of embedded SQL, no SOC, tied to Oracle, little messy, but it works.
They implement an "Application Manager", which is essentially another Model type layer on top of the Web Form application.
Anyways, I am looking for suggestions on using ASP.NET MVC 3 with their existing Business Object Framework, and I have come up with the following idea.
Implement a layer between their Business Object Framework and the ASP.NET MVC 3 Applications that serves View Models to and from the controllers. This layer would be where:
Their existing Business Rules are validated and any errors are ported
back to the Web Application.
Data is retrieved from their Objects and
turned into view models to give back to the controllers.
Where controllers would hand back View Models to persist to the DB, maybe
using AutoMapper to map them back to their Business Objects.
It would sort of be a service type layer??
Any suggestions would be greatly appreciated.
Everything always changing, see my answer here for this question
MVC Design and architecture advices
General question, when do people access their DAL in a prism application?
That is to say, if a module requires data do you query the DAL on the module load (I've currently been using OnImportsSatisfiedandINavigationAware.OnNavigatedTo` (passing in a parameter from the previous view).
Obviously I wouldn't want different modules to be tightly coupled but for an example where I have multiple views in a module would it be better from the UI responsiveness point of view to retrieve the data up front and pass it into the new view?
Anyone got any thoughts on this that they could share? Thanks.
In my current project we build the application this way that all view models asynchronouls query their data from one wcf service proxy after their own initialization. The proxy itself queries them from the server and caches it internally. Thus you have to think about a caching strategy.
But this leads to the following behaviour: The user interface is build up by the region manager. At the beginning it is empty. After a short time the data arrives from the server, the view models get their model, read the data from it, the data context of the view (which is the view model) is filled up and so the view is populated.
The answer to your question is: The view model queries the DAL (in my case the wcf service proxy) after it's creation in asynchronous way.
I'm making a ASP.NET MVC application using EF4, using the Controller --> View Model --> Service Layer --> Repository --> Data Model (EF) approach.
My question is where does the business logic/validation live at?
Should I be making copies of the domain objects into view objects and validating there? Seems like a lot of extra work to duplicate the domain objects into objects for the view models.
I am using POCO's generated using the T4 templates.
Personally I put business validation logic (things like username is already taken, cannot wire money because of insufficient funds, ...) in the Service Layer and things like the username fields is required on the view model.
I actually like #Darin Dimitrov's method and this is what I'm currently using on my project. And in order to take advantage of displaying error messages just like you would do with using attributes, you can use a wrapper around the ModelState as explained in this article.