(public).sospep.subjects ~ view article ~ migrating-web-pages-mvc

<h1 style="text-align: center;">migrating&nbsp;an app FROM: asp.net web pages app&nbsp;TO: asp.net MVC</h1>
<h2>[WHAT]</h2>
<ol>
<li>]&nbsp;this is part 1 of 3 part series, will migrate the&nbsp;example Bakery site&nbsp;app form Web Pages to MVC. Part 1 covers the v and c parts of MVC, while parts 2 and 3 cover the m part</li>
</ol>
<h2>[WHY]</h2>
<ol>
<li><strong>] WHY - REASON - dont do it</strong> - for performance or scalabity gains, web pages is running on the same asp.net underneath and is just as fast and as scalable as MVC</li>
<li>] the Web Pages framework was partly introduced as a smoother on-ramp to ASP.NET development because it was (and still is) considered that MVC is a complex framework. It has a number of moving parts and their roles will be explained here by comparing them to equivalent parts of the Web Pages framework. Your work with Razor Web Pages certainly puts you at an advantage in terms of learning about MVC.</li>
<li>+] web pages, web matrix is being&nbsp;phased out by msft - &nbsp;</li>
</ol>
<h2>[WHERE]</h2>
<ol>
<li><strong>] READ THE COMPLETE ARTICLE SERIES - ON migrating from web pages to mvc</strong></li>
<ol>
<li>part 1 - <a href="http://www.mikesdotnetting.com/article/262/migrating-from-razor-web-pages-to-asp-net-mvc-5-views-and-controllers">http://www.mikesdotnetting.com/article/262/migrating-from-razor-web-pages-to-asp-net-mvc-5-views-and-controllers</a></li>
<li>part 2 -</li>
<li>part 3 -</li>
</ol></ol>
<h2>[WHEN]</h2>
<ol>
<li>] 2015-02-16 (part 1)</li>
</ol>
<h2>[EXAMPLE]</h2>
<ol>
<li><strong>[SUMMARY] &nbsp;part 1&nbsp;- 2015-02-16&nbsp;</strong></li>
<ol>
<li><strong>] THE Bakery Site</strong> - webmatrix template for a simple application that features a three-step ordering process: bakery items are displayed; the user selects one by clicking on it; the user completes a form and submits it. Product details are stored in a database and their images in the file system</li>
<li><strong>] MVC - </strong>architectural pattern chiefly concerned with generating appropriate UI based on user input.&nbsp;</li>
<li>] key selling points behind the pattern is that it promotes "separation of concerns". The concerns that should be separated are the logical layers within an application. These include ] presentation, ] business logic, ] data access and any ] service layers.</li>
<li>+] <span style="text-decoration: underline;">more on MVC</span> - the design pattern -&gt; intro to asp.net MVC series</li>
<li>] The reasons why you should consider separating your concerns include ] easier maintenance, ] greater possible reuse, ] ease of testing.</li>
<li><strong><em>] The Razor Web Pages development model doesn't do anything to promote good separation</em></strong>. A typical page consists of database calls, business logic such as validation and calculations, service layer artifacts like email generation and sending, and of course, presentational HTML intermixed with server side code.</li>
<li>] If you have tried to keep as much server-side code as possible in a code block at the top of the page, you have already exercised a certain separation and that will make your migration much eaiser. The Bakery template, along with the Photo Gallery and Starter Site templates all demonstrate some discipline in terms of where the server side code goes</li>
<li><strong>] MVC - what goes where -</strong>&nbsp; The <strong>View</strong> belongs in the presentational layer and generally, the stuff below the code block in your Razor Web Page will allow itself to be transplanted straight into an MVC Razor View file with few complaints (so long as you don't have any database calls down there...).</li>
<li>] Database calls, emailing and validation are all part of the <strong>Model</strong>, which is really a catch-all area for server-side logic. Therefore the contents of your top-of-the-page code block will find itself in one form or another somewhere in the Model.</li>
<li>] The <strong>Controller</strong> is the new bit to Web Pages developers. Its role is to process incoming requests, ensure that appropriate application logic is executed based on the request, and to see that the correct response is generated by calling a particular View. It basically controls the flow of the application between browser and server. Some of these ideas can seem abstract at first, but they soon become clearer through example. And so to work.</li>
<li><strong>+] illustration - anatomy of a web pages app -</strong></li>
<ol>
<li>] top code block = server side code, ( declare layout page, )</li>
<li>] top code block = server side POSTed data processing</li>
<li>] middle = view code with @razor&nbsp;variables&nbsp;</li>
<li>]</li>
</ol>
<li><strong>] CREATING AN MVC APPLICATION - </strong>ASP.NET MVC applications are built using what is known as the Web <em>Application</em> Project type. Web Pages sites are built using the Web <em>Site</em> Project type. The chief difference between the two of them is that Web Application projects must be precompiled before they are deployed to a web server, while you can FTP raw source files from a Web Site project to a web server, and they will be compiled on demand when the first request comes into the application. WebMatrix only supports Web Site projects, so it is unsuitable for building MVC sites. So <em>the migration will involve creating a new MVC application in Visual Studio</em>, and <em>porting as much code across to it as possible</em></li>
<li>+] illustration - project structure - <a href="http://www.mikesdotnetting.com/images/02-02-2015-07-27-43.png" target="_blank">http://www.mikesdotnetting.com/images/02-02-2015-07-27-43.png</a>&nbsp;</li>
<li>*] contains directories for /models /views and /controllers - The only one that the framework relies on by default is the Views folder. ASP.NET MVC expects to find view files there. You can place controllers and model classes pretty much anywhere within your application. Typically, most developers put controller classes into the Controllers folder, but will place other classes that belong to the Model wherever they like. Some even delete the Models folder up front. In the second and third parts of this tutorial, you will place Model code in a number of different locations. </li>
<li>] you should <strong>copy across the database and image files from the existing Bakery site</strong>. You should do this by right clicking on folders and choosing <strong>Add Existing Item</strong>. That way the items are included in the project automatically.</li>
<li><strong>] LAYOUTS AND VIEWS</strong></li>
<ol>
<li>] The <em>Views</em> folder contains a folder per controller and one called <em>Shared</em>.</li>
<li>] By convention, you place layout and "partial" files into the <em>Shared</em> folder.</li>
<li>] <em><strong>Partial files</strong> are the MVC equivalent to the content blocks which are called via the <strong><code>RenderPage</code></strong> method in Web Pages.</em> The following code shows the Bakery template layout page transplanted to the <em>Views\Shared\_Layout.cshtml</em> file. Changes to the code are highlighted in yellow</li>
</ol>
<li><strong>] ROUTING AND CONTROLLERS</strong></li>
<li><strong>] SUMMARY</strong></li>
</ol></ol>
<h2>[HOW-TO]</h2>
<ol>
<li>]</li>
</ol>
<h2>[REFERENCE]</h2>
<ol>
<li>]</li>
</ol>
<h1 style="text-align: center;">&nbsp;</h1>

~ view article ~ Chapter] ch-999-index-asp.net FROM [ Book] asp.net IN [ libraries] technology-developer-www