Is it possible to call multiple stored procedures (not multiple result sets from a procedure) and display results on a single page in ASP.NET MVC 3 application?
From what I understand only one Model can created on any single page and my stored procedure is already tied to that Model. I would like to call another procedure and display that result as well on my page
I think the root problem is to understand the meaning of the Model in the MVC pattern.
First of all,
The model consists of application data and business rules, and the controller mediates input, converting it to commands for the model or view.[3] A view can be any output representation of data, such as a chart or a diagram
source
In ASP.Net MVC you link a model to your view, this model should not be part of your domain logic or any domain object
The real model (using the meaning of the MVC pattern) is represented by your domain objects.
So what should you put inside the object that you link to your view??
These objects should contain a representation of the view, in other words simple DTO's containing only the data that is going to be used in the view and nothing more. These models should represent the data being used in the view. If you follow this approach, and you need to display more data in the page, you only need to add another property to this model and voila, you can use it from your view.
In a CQRS architecture, these DTO's should be populated by the Query repositories.
If you do not have a CQRS architecture, just populate these objects in your domain, repositories, etc. Do not do it inside the controller, keep your controllers clean and simple, by making calls to your real domain using services or repositories
Try to avoid the reuse of these DTO's, they should belong to one view only. And do yourself a favor and do not try to reuse a domain object instead of a DTO just to use it as the model.
Following this approach your view-models will be clean, since they will be only DTO's and only containing the data needed by the view. And you can fill these DTO's from different sources, even from different databases if you want.
When you want to perform an action you would read from the model the data provided by the user, and with this data you would call your domain through repositories, services or in a CQRS arc. using commands
The simple answer to your question is "yes".
I suggest you do some more research (ie reading articles and looking at sample apps) into MVC and concentrate on understanding these points:
The Model is a class used to group the data you want to display in the View. It can be populated by a variety of methods and does not have to be the domain object or the pure representation of the database result.
A "page" (the concept of what a user sees in their browser window) can be made up from one or more Views. Each View can be responsible for displaying one type of Model allowing for reuse, but a "page" can have multiple Views.
Models are not "tied" to stored procedures. Perhaps you are using an ORM tool that returns a DTO class (which you call model)? This doesn't have to be the Model used by the View. The Controller could compose several of these DTO classes into one Model class.
N-tier application design where database access is separated from the display logic. MVC tries to encourage this but it still has to be done correctly to avoid tying yourself in knots.
Good luck!
Related
I've recently started developing in .NET core.
When developing I encountered the situation that I have to make very similair models that aren't quite the same. For example, let's talk about a booking model:
Frontend: Here I need a model that gets posted as a JSON to my backend and gets deserliazed to a sort of FrontendBooking model.
Backend: I need to add Customer data to the booking, therefore I need to add fields like: CustomerName and CustomerAddress, based on their CustomerId. The backend needs to provide this data, I do not want the frontend to determine these fields. I combine these models to prepare it for an API call. To a model called RequestBooking.
API: I sent RequestBooking to an API and get a response with a similair object that has for example a Status and BookingId added, this was added to the model by the API. So I need to deserialize this to an object called: ResponseBooking.
Database: Finally I wish to store the object to a database, not all properties of the model are relevant however, therefore I create another model called: DatabaseBooking and store this to the databse.
When a property is added, removed or changed. Then I'll have to change it for each of these models.
Is there a design pattern or some other solution, so this is more manageable?
Also, what is best practise for naming these models? Naming them all Booking doesn't feel quite right and adding what they're used for doesn't feel quite right either.
Thanks in advance.
Well, in general you will need different (although similar) models at least at these levels:
Server: here you can make use of Domain Driven Design. You will have an object Booking that is responsible for its logic and contain all properties and methods like e.g. MarkAsCancelled. You can use Entity Framework to use the same object in the database, which will correspond to a database table. EF allows you to mark some properties as not being saved in the DB. Also you can set up EF in the DbContext class and thus not use DB specific attributes in the class. So one object for DB and backend business logic.
API: obviously you cannot send your domain object to the API, e.g. REST. In the API you may want to combine properties of several domain objects or hide some properties. You will have to define a set of Data Transfer Objects (DTOs), e.g. BookingDto. How to convert your domain objects to DTOs? Solutions like AutoMapper may help. You just set up convertion rules once.
Now you can describe your API in e.g. Swagger. With Swagger Codegen you can than generate code for your server (.net) and client (e.g. JS).
In the end you will have to support the following:
API definition (e.g. Swagger). Code for server DTOs and client
objects is autogenerated. You modify API definition once, both sides
get new objects.
DDD Models that also are used for the Database. They
may be faily independent from your DTOs. Mapping is handled for you
semi-automatically by e.g. Automapper
All said is just a suggestion. All the layers and number of objects can and should be adapted to the specific needs of your project. E.g. you may want to use separate objects for the database if you are not using a relational mapper like EF or do not want to mix DB and logic.
I see references to "best practice", but why is it better to use a ViewBag object versus an Application object when accessing static data in the view?
Both are possible. Suppose you want to add an object to every view but not necessarily pass it to view the model (since there may not even be a model for a given view)?
This could be done several ways, like with a global filter, but accessing an application variable is much more convenient.
Both are nasty workarounds that bypass everything that MVC stands for.
In the Model-View-Controller pattern, your Controller prepares a Model containing all values necessary to populate the View, and the View in turn displays the Model properties the way it's intended to.
Any way you use to circumvent that pattern, like ViewBag, Session or Application variables, are anti-patterns that defeat the MVC way - as long as you access those variables directly from the View.
See also Pass data to layout that are common to all pages and Create ViewModel for Navigation: if you need certain values on all pages, consider using a base viewmodel or partial views.
And yes, this discussion borders on pragmatic/purist. If you for example have a menu that's the same for every user, but which is loaded from a database, then sure, go ahead and store it in an Application variable for caching purposes to load it once per AppDomain. But then still use a base ViewModel or Partial to render that menu.
I wouldn't say putting data in a view bag is a best practice. I would say using a view model is a best practice.
Suppose you want to add object to every view but not necessarily pass
it to view the model (since there may not even be a model for a given
view).
Even if you haven't define a view model, conceptually there is a model is you are passing data to the view.
See Why do we use ViewModels?
If the data is on every view, you could create a base view model that every model inherits from that contains the universal data.
you could also create a partial view with its own view model that is then applied to each page.
Normally I design ViewModels taking in consideration the business or functional concepts of the application.
For example, if you are displaying an invoice, the view model should contain all the properties related to invoices that needs to be displayed on that specific view. I wouldn't use ViewBags/ViewData for this purposes.
On the ViewBag I normally put other and "more ancillary" properties like, for example, a boolean for showing/hiding some part of the view, or maybe for some other "not business relevant" properties.
Of course some people could disagree with this and would put everything on the Viewmodels, some others not. This is a decision you must take at the beginning so you can be consistent in the way you design across the application.
I've noticed in ASP.NET MVC, it's commonplace to use model binding and validation annotations in conjunction with business objects that also interact with the database.
Unfortunately, this means that the scope of the request and the validation taking place must always be 1:1 with domain models. At the very least not without having to code a bunch of exceptions.
If I'm looking for a way to do contextual validation in ASP.NET MVC, are there any examples of or is it an accepted practice already to use POCO classes that represent the incoming data?
Let's say I call these "Request Models". An example might be that I create a class called UpdateUserRequestModel. I define only the data that I allow for a user update, then, I have MVC bind the values into this surrogate model. Later in my controller/services, I access the request model's public properties for the values I wish to move over to the user object.
So, the question here is: Is there already any example of this practice in commonly accepted ASP.NET MVC conventions? Does it have a particular name? Failing that, when I wish to do contextual validation, are there any better options than the default model binders and value providers that MVC ships with?
I do it on my apps. I validate actions the user performs, putting validation attributes etc on that view model that represents that action (conveniently models the form in the view and model binds the result on the way back). I even ported the ContosoUniversity app to reflect this style:
https://github.com/jbogard/ContosoUniversity
I have MVC 3 web app where I get record(s) from DB which is used to render page elements and populate different partial views.
I have classes that represent these DB objects (service layer).
I have also separate set of classes which holds models get returned by the controllers to the view(s).
In my controller, I query DB that returns object to represent DB record.
Then I transfer (MAP) that DB Object to object that Represent the model used by the view(s)
These classes are big and I have to write lots of code in the controller to map.
In most cases I only have some properties which are different.
It seems lots of extra work to do this mapping & lots of code to do the mapping
That is why I am asking.
Is this the correct design approach of developing in MVC framework?
If no, then do you have some pointers that outline the best practice on this aspect.
The Model or ViewModel should only contain information that is used by the View. In some cases, this can be almost identical to what the objects you get from the database are,but this is not always the case. Keeping these concerns separate is good for a number of reasons beyond the scope of a stackoverflow answer. On a side note, I hope you have a separate data access layer and am not querying the database , entity framework or service directly from the controller, again, just to keep those concerns separate.
You can use AutoMapper to map between your DB objects and view models automatically.
Example:
SomeViewModel model = Mapper.Map<SomeViewModel>(someDbObj);
Getting started guide.
In our ASP.NET MVC 3 application, we displays a lot of information from various data sources as listed below
Action method parameters
Query string (which can not be used in model binding)
Session
WCF Service
Database
We have to combine the data from all above stated data sources, format and dispay it in a view.
How to divide the classes so that it will have better maintenability?
If we use view models, how to construct the view model by combining all information?
Where to Keep the mapping between Domain Model and View Model and vice Versa?
How to divide the classes so that it will have better maintenability?
By defining view models that will be specifically tailored for the requirements of your views.
If we use view models, how to construct view model by combining all information?
You could define a view model that will contain all the necessary information you need to display in a given view. If there are shared widgets between your views you could have child view models that the main view model could reference as properties (composition). The child view models could then be reused in other contexts.