ASP.NET MVC 4 project without ORM
I am trying to use ASP.NET MVC without EF and possibly LINQ. For starters, I created only one table / model / controller / view on the base ASP.net mvc template in VS2010 (only the index page and Index method implemented). I am currently using try / error as all tutorials on the web are based on EF and I have an inline c background.
My questions:
-
Is the architecture built correctly?
-
I've seen the repository pattern used in some open source projects such as forums. What is its advantage and how does it fit into it, does it replace DAL?
-
Should I be passing datatables to view or objects representing datatable data?
-
Can I submit more than one model to the shaver page? How can I list, for example, two different tables?
-
Is it better to put all the DAL code in one file?
DAL:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Data;
using System.Configuration;
using MySql.Data.MySqlClient;
namespace MvcApplication1.Models
{
public class DAL
{
public DAL()
{ }
public DataTable getDataTable(string tableName)
{
using (MySqlConnection conn = new MySqlConnection(ConfigurationManager.ConnectionStrings["MySQLConn"].ConnectionString))
{
using (MySqlCommand command = conn.CreateCommand())
{
command.CommandText = "select * from " + tableName;
command.CommandType = CommandType.Text;
conn.Open();
var table = new DataTable();
table.Load(command.ExecuteReader());
return table;
}
}
}
}
}
the Product.cs class, which represents the product table in code:
namespace MvcApplication1.Models
{
public class Product
{
public int ProductId { get; set; }
public string Name { get; set; }
public string Producer { get; set; }
public int UnitPrice { get; set; }
}
}
ProductController.cs
namespace MvcApplication1.Controllers
{
public class ProductController : Controller
{
//
// GET: /Product/
DAL dal = new DAL();
public ActionResult Index()
{
DataTable dt = dal.getDataTable("Product");
Product[] products = new Product[dt.Rows.Count];
for (int i = 0; i < dt.Rows.Count; i++)
{
products[i] = new Product();
products[i].ProductId = (int)dt.Rows[i]["ProductId"];
products[i].Name = (string)dt.Rows[i]["Name"];
products[i].Producer = (string)dt.Rows[i]["Producer"];
products[i].UnitPrice = Decimal.ToInt32((decimal)dt.Rows[i]["UnitPrice"]);
}
return View(products);
}
........
........
}
Index.cshtml:
@model IEnumerable<MvcApplication1.Models.Product>
@{
ViewBag.Title = "Index";
}
<h2>Index</h2>
@foreach (var item in Model)
{
<tr>
<td>
@Html.DisplayFor(modelItem => item.ProductId)
</td>
<td>
@Html.DisplayFor(modelItem => item.Name)
</td>
<td>
@Html.DisplayFor(modelItem => item.Producer)
</td>
<td>
@Html.DisplayFor(modelItem => item.UnitPrice)
</td>
<td>
@Html.ActionLink("Edit", "Edit", new { id=item.ProductId }) |
@Html.ActionLink("Details", "Details", new { id=item.ProductId }) |
@Html.ActionLink("Delete", "Delete", new { id=item.ProductId })
</td>
<br>
</tr>
}
source to share
I've seen the repository pattern used in some open source projects such as pre-forums. What is its advantage and how does it fit into it, does it replace DAL?
The advantage of the repository pattern is that it allows you to disable data access / ORM logic. For example, if you want to switch from Entity Framework to NHibernate, you just update your registrations inside your IoC container and like magic your code uses NHibernate with 0 knowledge of what you ever did switch. This allows your code to be agnostic to the underlying persistence framework. For all it knows, the result code must come from a file, a web service call, or an in-memory list. You will also get reusability in the event that you have to make the same request from another component. Another enhancement is unit testing. With your current implementation, you cannot unit test your controller as it is going to connect directly to your database every time,so by definition makes it an integration test. You will of course want to use an ORM, or you will write the same code over and over until it makes you cry. Setting / disabling connections, inject listing all your primitives to native .NET types, etc. Working with native ADO.NET is a thing of the past. Make your life easier and use ORM. At the same time, great responsibility comes with great power. ORMs can be a nightmare if you don't validate the queries that are generated and executed against your database. If not used properly, they will cause performance problems. You will be able to use LINQ for most of your queries, but sometimes you have to get dirty funky and work with raw SQL. You ORM will still be able to handle both scenarios.of course, you will want to use an ORM, or you will write the same code over and over until it makes you cry. Setting / disabling connections, inject listing all your primitives to native .NET types, etc. Working with native ADO.NET is a thing of the past. Make your life easier and use ORM. At the same time, great responsibility comes with great power. ORMs can be a nightmare if you don't validate the queries that are generated and executed against your database. If not used properly, they will cause performance problems. You will be able to use LINQ for most of your queries, but sometimes you have to get dirty funky and work with raw SQL. You ORM will still be able to handle both scenarios.of course, you will want to use an ORM, or you will write the same code over and over until it makes you cry. Setting / disabling connections, inject listing all your primitives to native .NET types, etc. Working with native ADO.NET is a thing of the past. Make your life easier and use ORM. At the same time, great responsibility comes with great power. ORMs can be a nightmare if you don't validate the queries that are generated and executed against your database. If not used properly, they will cause performance problems. You will be able to use LINQ for most of your queries, but sometimes you have to get dirty funky and work with raw SQL. You ORM will still be able to handle both scenarios.until he makes you cry. Setting / disabling connections, inject listing all your primitives to native .NET types, etc. Working with native ADO.NET is a thing of the past. Make your life easier and use ORM. At the same time, great responsibility comes with great power. ORMs can be a nightmare if you don't validate the queries that are generated and executed against your database. If not used properly, they will cause performance problems. You will be able to use LINQ for most of your queries, but sometimes you have to get dirty funky and work with raw SQL. You ORM will still be able to handle both scenarios.until he makes you cry. Setting / disabling connections, inject listing all your primitives to native .NET types, etc. Working with native ADO.NET is a thing of the past. Make your life easier and use ORM. At the same time, great responsibility comes with great power. ORMs can be a nightmare if you don't validate the queries that are generated and executed against your database. If not used properly, they will cause performance problems. You will be able to use LINQ for most of your queries, but sometimes you have to get dirty funky and work with raw SQL. You ORM will still be able to handle both scenarios.Make your life easier and use ORM. At the same time, great responsibility comes with great power. ORMs can be a nightmare if you don't validate the queries that are generated and executed against your database. If not used properly, they will cause performance problems. You will be able to use LINQ for most of your queries, but sometimes you have to get dirty funky and work with raw SQL. You ORM will still be able to handle both scenarios.Make your life easier and use ORM. At the same time, great responsibility comes with great power. ORMs can be a nightmare if you don't validate the queries that are generated and executed against your database. If not used properly, they will cause performance problems. You will be able to use LINQ for most of your queries, but sometimes you have to get dirty funky and work with raw SQL. You ORM will still be able to handle both scenarios.but sometimes you have to get dirty funky and work with raw SQL. You ORM will still be able to handle both scenarios.but sometimes you have to get dirty funky and work with raw SQL. You ORM will still be able to handle both scenarios.
Should I pass data to view or objects that represent data?
You don't want to transfer data, of course. You want to pass view models or objects to your view. The view does not need to know anything about the database. All you do is provide it with data and it displays on the screen without knowing the source of that data. You want to be careful about passing entities right in your mind if you are using something like NHibernate because you are having problems with lazy loading and N + 1 queries. View models are usually minified versions of your object. For example, if you have an object with 4 properties, but only 2/4 of those properties are required to view, you should create a separate view model with 2 properties and use a mapping library like Automapper to map to your entity to view the model ...
Can I submit more than one model to the shaver page? How can I list 2 different tables for example?
It's pretty straightforward. You create a top level object and give it 2 properties to represent the objects you want to access.
public class MyViewModel
{
public Entity1 FirstObject { get; set; }
public Entity2 SecondObject { get; set; }
}
Then you will create a strongly typed view and render FirstObject and SecondObject with the strongly typed view helpers you used in your razor view posted in your question. @ Html.TextBoxFor () etc.
Finally, your controller will take MyViewModel as an argument and populate the FirstObject and SecondObject based on the form inputs that are displayed in your view.
Is it better to put all the DAL code in one file?
You want to put the corresponding DAL code in the same file. Things are usually displayed as a table, but it all depends on the relationship between your objects (for example, your common root). What you don't want to do is blindly implement one repository per table. You just end up with a truly procedural and anemic data model that will stitch together object and relationship graphs across multiple calls to the database. I would recommend looking at Domain Driven Design for a good idea on how to fix this problem.
I just scratched the surface here. You will need to pick up the latest patterns and techniques if you want to get it right. This is a completely different movement. Not like the good old days of monolithic code behind files, view state, and DataGrid controls. There are some really good books out there, for example:
Application Development Brownfield Domain Driven Project (Eric Evans) Pure Coder (Robert C Martin) Refactoring: Improving the Design of Existing Code (Martin Fowler) Enterprise Application Architecture Patterns (Martin Fowler)
I'm not saying I read all of these books verbatim, but I highly recommend the first 2. I'm sure the community will have more to say about these development methods, but that's my point of view on all of this. Thanks and good luck.
source to share