Now the time has come for the basic infrastructure for Asp.net MVC. So, among other things: ViewData Model, Commands, adapting to the new views structure. In addition, I will discuss briefly automappera.
ViewData Model
What a monster of many probably will ask. These are the models (classes) used to transmit data from the controller to the view. Thanks to him views may be strongly typed to a particular model. We can thus avoid the use of ViewData and we have all the data from the view nicely in a single model. This greatly facilitates access to data. I will not elaborate too much on this subject but significantly expanded explanation can be found on this blog
BaseViewData
{public string Sitetitle {get; set;}
public string PageTitle {get; set;} public string MetaKeywords {get; set;} public string
MetaDescription {get; set;}}
Then is a concrete example, the controller for ViewDataModel AccountViewData which is in the constructor sets the page title. Sample Implementation Account for the controller: public class
AccountViewData: BaseViewData
{private string
_pageTitle = "Account";
public AccountViewData () {
PageTitle = _pageTitle;
}} And then
have very definite views of models that inherit from the model controller for example: public class
Password {get; set;}
LogOnViewData: AccountViewData
{
[Required]
[DisplayName ("User name")] public string
UserName {get; set;}
[Required ]
[DataType (DataType.Password)]
[DisplayName ("Password")] public string
[DisplayName ("Remember me?")] public boolCommands
rememberMe {get; set;
}}
ViewData generation of models is done using the factory so that a particular controller does not have to know a variable with Site.Mastera. Examples of the creation of a model for the controller ViewData Account Login View Public ActionResult
Logon () {
LogOnViewData _viewDataFactory.Create \u0026lt;LogOnViewData> view = ();
return View (view);}
Next item associated with the views of the commandy. They are used to bound with BIA data that form to send us a specific controller. This allows us to write a public
ActionResult Register (RegisterCommnad command)
instead: public
ActionResult Register (FormCollection formitems)
and draw from this field.
Automapper
Automapper is a small library to facilitate the mapping of object to another object. This is useful mainly in the transformation of the entity at the DTI. The same map after setting looks like this:testuser User testuser = new ();
UserDTO testUserDTO = Mapper.Map \u0026lt;User, UserDTO> (testuser);
As you can see nice, easy and fun. Now a few words about the configuration. Let's start by creating a profile that is the class who has information on how to map the objects. It looks like this: public class
DefaultProfile: Profiles
{public override string ProfileName
{get {
return "DefaultProfile"
}}
protected override void Configure () {
/ / configure here
types / / Example of the User UserDTO
Mapper.CreateMap \u0026lt;User, UserDTO & # 62; ()
. ForMember (dest => dest.Id, opt => opt.MapFrom (src => src.Id))
/ / gave only the first field analogy, but the rest
}}
Then we create a Bootstrapper task that will be it for us at the beginning of configurations wczytywał: public class
AutoMapperConfiguratorTask : BootstrapperTask
{protected override
TaskContinuation ExecuteCore (IServiceLocator serviceLocator)
{
Mapper.Initialize (x => x.AddProfile \u0026lt;DefaultProfile> ());
TaskContinuation.Continue return;}
}
I already have configured automappera. This is a very useful library for easy lives. In addition to these major changes as described in the alert. I added a simple service associated with the user and accordingly modified the controllers and views. So I have a simple login working.
0 comments:
Post a Comment