We can implement validation in two ways 1) Client side validation 2) Server side validation
In Server side by default we make use of existing validation through DataAnnotations Declare default validation attribute like “Required”, “RegularExpression” , “Range” on top of required class properties to enforce certain rules.
Other way is by implementing IvalidatableObject
1) This interface contain Validate(), its return type is Ienumerable 2) By implementing IvalidatableObject interface in a class and implement our own custom rules and condition inside the Validate() 3) Since it could be implement our own custom rules and condition it is easy for cross validation property But the same has limitation in reusability because sometime it become tightly coupled.
Model binding in controller > By default model validation handled during model binding process, when data requested and start binding with class property, it apply assigned attribute validation attribute classes to check data is correct. > For validation implemented using IvalidatableObject interface will happen next to prebuilt validation, this is because to check each property has loaded with correct and required data, before implemeting cross validation property. > After this two steps completed the results of validation stored in “ModelState” property of Controller. So even when we implement our custom validation using IvalidatableObject interface, those validation result will also automatically updated in “ModelState.IsValid” property
The other way is by using ValidationAttribute class as below
Enable-Migrations: Enables the migration in your project by creating a Configuration class. PM> Enable-Migrations
Add-Migration: Creates a new migration class as per specified name with the Up() and Down() methods. PM> Add-Migration"MigrationName" The above command will create a “timestamp_MigrationName”.cs file with the Up() and Down() methods
Update-Database: Executes the last migration file created by the Add-Migration command and applies changes to the database schema. PM> Update-Database
Rollback Migration to previous one PM> update-database -TargetMigration:"timestamp_MigrationName“
In .net core while register services with dependency injection container in “ConfigureServices(IServiceCollection services)” in Startup.cs, we can define the lifetime of the instance across the application using any one of the three methods.
Only one instance will create and that instance will be available through out the application.
So that when ever we need the instance that created during application start we could able to access it at any point in the application.
At any number of http request we could able to access the same instance
For each http request new instance will gets created.
The instance gets created using AddScoped, will be alive only for that particular http request
Irrespective of http request, every time when we look for an instance, it will create an instance every time
Example, in an single http request if we are trying to access Student repository instance more than a time, each time it will create new instance separately
Get the website requirment, analyze the site’s requirements, breakdown into smaller entities, using entities build normalized sitecore data template, then work further understand the content structure.
To build good template, should aware of below checklist
– Based on the site’s requirment think about entities and fields.
– Group all releted fields under logical section.
– Identify all common fields and create a base template.
– Field name used should be easily understand by business users.
– “Display Name” property to provide friendly name to an item.
– Always set default values in standard values.
– Apply Icon to templates, so that it is easy to recognize.
– Presentation should be configured in standard values.
– Utilize branch templates for predefined structure creation.
Once the templates have been created, you need to begin work on creating Content Item in content tree.
– As a standard, try not to have more than 100 items under particular node. If expecting more than 100, then consider using buckets or create folders in a way that it doesn’t exceed more then 100 child per folder/item.
– Try to have only page items created under home page.
– Make sure we have security added for items based on user access roles.
– For faster access index should be configured.
– Also maintain minimal version for each item.
Now the content structure is ready, let’s get started on creating the presentation
– Make sure all the LAYOUTS are created under ‘/Sitecore/Layout/Layouts’, can also create sub folders if needed with access limitation.
– For each device layout should not have more than 3 layouts structure.
– Layout details should be assigned in standard values and not in Template/Item level.
– Use Field Renderer object to render the fields on presentation.
– Caching options should be configured whenever the controls are used, based on the control definitions.
1) New flexible and cross-platform runtime
2) New modular HTTP request pipeline
3) Cloud-ready environment configuration
4) Unified programming model that combines MVC, Web API, and Web Pages
5) Ability to see changes without re-building the project
6) Side-by-side versioning of the .NET Framework
7) Ability to self-host or host on IIS
8) New tools in Visual Studio 2015
9) Open source in GitHub
Here are some helpful links to get you started with ASP.NET 5 Preview:
I have seen many people using DataReader incorrectly. In this post, I will try to explain some good practices that can be followed when reading from a data reader. Consider the following problematic code,
How many problems can you figure out from the above code? There are many problems with this code,