I am starting with the premise that the out of the box layout supporting separation of concerns will make learning MVC .Net development easy enough to do on my own. The project scope is to make a simple web based data generator that uses Windows authorization and the defined database security to allow people to create test data in an environment they have permission to do CRUD operations in w/o having to create an environment manager. The features will be selecting a client to create the record set for, ensuring the data generated maintains referential integrity across 15 defined data sources, that the output will be a correctly delimited set of flat files that have names identifying them as a single test set. Business rules will be lightly modeled in the generator but it is assumed the user has some understanding of the use cases they are trying to model.
How do I link a database project to a web project?
How do I deploy my projects?
I want to use database first EF in this as I model better in SQL.
I will need to learn some razor syntax to access methods in my classes for routes
What controls the routes and should I care?
Do I bother with CI and unit tests for this learning experience?
How do I add RI to the model
How do I conduct CRUD operations from a web UI?
How do I pull a full related record set into the app for management?
What is the difference between selecting ADO.NET Entity Data Model and EF 6.X DbContextGenerator?
How do I allow people to select from different database projects as templates for the test data? Do I use EnvironmentVariableTarget?
Let's start with this tutorial:
http://www.asp.net/mvc/tutorials/mvc-5/introduction/
MVC is a pattern before a technology. It is all about separation of concerns.
Models: Classes that represent the data of the application and that use validation logic to enforce business rules for that data.
Views: Template files that your application uses to dynamically generate HTML responses.
Controllers: Classes that handle incoming browser requests, retrieve model data, and then specify view templates that return a response to the browser.
The URL structure dictates the routes in the code. Each page will be public and should be named meaningfully.
ASP.NET MVC invokes different controller classes (and different action methods within them) depending on the incoming URL. The default URL routing logic used by ASP.NET MVC uses a format like this to determine what code to invoke:
/[Controller]/[ActionName]/[Parameters]
A method named
Index is the default method that will be called on a controller if one is not explicitly specified.
Step 1... Think about how you want to move through the site. Make sketches of the information architecture. Write out some requirements. Do that in the reverse order of what I write here.
If this is a production site think of layouts, fonts, colors, dynamic design elements and the other crap people take for granted as differentiators of web products.
Create an MVC project in TFS (File - New - Project - Template).
Add the unit tests now as it is easier to add the folders and not use them than to need to add them later.
Set the security model you expect to use. If this requires AD groups to be setup...do it now. Avoid rework.
Add a few pages and your basic branding. I need to look up the files I did this in, but it helped me quickly represent the basic information arcitecture in the view classes. It also makes my app look less like ass when I debug.
To add settings right click the project - Properties - Settings
I added two settings before coding: GenerateFiles as a bool and SecurityModel as a string.
Use (localdb)\Projects as the initial source of your model.
Link the database project to the web project, and in the web project make the database project a dependency.
When learning MVC do not take the advice of some tutorials to use a file based storage database linked to the App_Data folder. This is not they way you would build a real site (unless your site has very limited functionality), so learn the right way by creating a real database (e.g. using SQL Express at home will want to add to App_Data...make it put the mdf file someplace outside the folder for the web tier).
In solution explorer right click Models - Add New -
Select Data from left side pane.
b.
Select the
ADO.NET Entity Data
Model.
c.
Give the name of your Entity Framework.
d.
After that press
OK.
(should I select the db context generator here if I am not using VS 2013)?
Generate from database.
New Connection if you did not create your web.config already
SQL Server -
name of a database server with your writable database
database name
security model
test connection
(Advanced - Encrypt if you want, connect retry, pooling info, replication for sql server, context connection, initial catelog if different than the db you are selecting)
Select your tables name the thing, take defaults unless you have a reason not to.
Right click in the black space. Add new association:
Include each PK/FK relationship and indicate the correct cardinality for these objects.
One struggle is know which of the many articles are useful
Typically when you generate an Entity Framework (.edmx) from database
and then try to create a MVC controller with read/write actions based on
this Entity Framework,
Deploying SQL stuff with the website varies by complexity of the database and rows of data in source control:
create a database
Setup the web config
Right click the project - Properties - Settings
There is a Package Publish SQL tab that pulls the connection info from the web config
There is a switch on the Package Publish Web tab to include/exclude the Package Publish SQL settings
http://msdn.microsoft.com/en-us/library/bb907585(v=vs.100).aspx
http://msdn.microsoft.com/en-us/library/dd465343%28VS.100%29.aspx
This is common sense but "If you are deploying a database to a production server, you might
want to prevent the Web site from responding to page requests during the
deployment process. This can help avoid errors that might result during
the time when changes are only partially completed."
How to: Prepare to Deploy a Web Project.
http://www.asp.net/mvc/tutorials/hands-on-labs/aspnet-mvc-4-models-and-data-access
http://www.mikesdotnetting.com/Article/185/Building-A-Razor-Web-Pages-Site-With-Database-First-And-Entity-Framework
http://jefferytay.wordpress.com/2013/02/19/asp-net-mvc4-how-to-use-a-database-first-ef-in-a-mvc-controller/
http://www.c-sharpcorner.com/uploadfile/raj1979/unit-testing-in-mvc-4-using-entity-framework/
http://www.mindstick.com/Articles/6dfea253-4698-4eb8-ab20-57d2aa61753a/?Fetch%20Data%20from%20Entity%20Framework%20Using%20ASP%20NET%20MVC4
http://sixrevisions.com/usabilityaccessibility/information-architecture-101-techniques-and-best-practices/
http://failuresincoding.blogspot.com/2011/12/entity-framework-provider-did-not.html
http://msdn.microsoft.com/en-us/data/jj613116.aspx
Links to articles on POCO and DTO...state manangement of data objects outside the framework.
A POCO follows the rules of OOP. It should (but doesn't have to) have state
and behavior. POCO comes from POJO, coined by Martin Fowler [
anecdote here].
He used the term POJO as a way to make it more sexy to reject the
framework heavy EJB implementations. POCO should be used in the same
context in .Net. Don't let frameworks dictate your object's design.
A DTO's only purpose is to transfer state, and should have no behavior. See Martin Fowler's
explanation of a DTO for an example of the use of this pattern.
Here's the difference:
POCO describes an approach to programming (good old fashioned object oriented programming), where
DTO is a pattern that is used to "transfer data" using objects.
While you can treat POCOs like DTOs, you run the risk of creating an
anemic domain model
if you do so. Additionally, there's a mismatch in structure, since
DTOs should be designed to transfer data, not to represent the true
structure of the business domain. The result of this is that DTOs tend
to be more flat than your actual domain.
In a domain of any reasonable complexity, you're almost always better
off creating separate domain POCOs and translating them to DTOs. DDD
(domain driven design) defines the
anti-corruption layer (another link
here, but best thing to do is
buy the book), which is a good structure that makes the segregation clear.
http://stackoverflow.com/questions/725348/poco-vs-dto
