I am learning asp.net MVC, as I have been using the sqlconnection, sqlcommands etc from my initial phases, I would like to initially start learning asp.net MVC without using the entity framework.
Can you give me a link or any idea of using the models to process data without using the entity framework.
So without entity framework you'll be using ADO.NET (See MSDN)
Those classes you mentioned SqlConnection, SqlCommand are part of the ADO.NET framework. The two Microsoft frameworks that build on this are Entity Framework and LinqToSQL.
If you don't want to us either you have to write you own models/classes, and then methods to persist those models into your database. (This is essentially what EF does) You won't get any LINQ or designers etc.
Also, ADO.NET does have a way to create strongly typed datasets. This might help a little.
What you are doing might help you understand whats going on under the covers, but do realize frameworks like Entity-Framework save a lot of time and effort by generating models for you.
Related
I've got a project I'm going to start. There will probably be less than 10 tables. ASP.NET MVC. I have next to no experience with EF, but a great deal of experience with ADO.net and SQL. Is it worth it for me to go with EF, or just use ADO.NET and write the code for the object mapping?
there will be user logins.
Since the application requires user login, you might want to consider using ASP.NET Identity rather than reinventing the wheel such as hashing algorithms.
ASP.NET Identity uses Entity Framework, but it doesn't require you to know EF. Since your project will be using EF, it is better to learn EF and use it instead of ADO.NET.
I am following Steven Sanderson's "Pro ASP.Net MVC2 Framewok", which uses Linq2SQL. He uses abstract factory approach to support unit testing and mocking, and writes model classes in a separate project to facilitate this.
I am using Linq to Entity Framework instead of Linq2SQL, and I have built an entity model in EF from an existing database. (I am new to all of this).
I don't quite understand if I'm getting this right, but I beleive I should still generate model classes defined outside of EF (a layer between EF and presentation?), even though I could just pass Linq2EF query results entities directly in as MVC's models (security? separation of concerns?).
So I'd like EF to stub the model classes for me instead of hand-coding them all from scratch. Is there an easy way to do this, or am I mis-interpreting what I need to do?
Take a look at this blog great resource on this subject.
If you are going to use ViewModels I highly recomend using AutoMapper from souceforge
I am developing a medium sized ASP.NET project using ASP.NET MVC and Entity Framework. I have developed a 3-tier system by setting up 3 Visual Studio projects and referencing them accordingly:
Presentation -- This is my MVC project and contains all the views and controllers. I deleted the model folder completely from this project as I am moving it to the BO project (see below)
Business Objects (BO) -- This project contains the "meat" of the application, and is where the real heart of the application is located. Here, objects are defined that represent things I'm trying to model in code (User, Facility, Appointment, etc.).
Data Access (DA) - This project is all Entity Framework so far.
The "problem" that I am having is that I am doing a lot of manual one-to-one mapping in the BO. For example, when a User.load() is called, I load the user from EF, then map a number of parameters (firstname, lastname, username, active, etc.) from the EF result to parameters on the object.
I see this as good and bad. Good: it disconnects EF from the project, so if I ever need to use another data store I'm not tied only to EF. Bad: it takes a little more time, because I have to setup each parameter and carefully handle them on Add(), Update(), etc. by implementing my own change tracking.
What do you think of this approach?
it disconnects EF from the project
Which is indeed good.
I am doing a lot of manual one-to-one mapping in the BO
I suggest you take a look at AutoMapper.
I find the book ASP.NET MVC in Action from Manning quite good. The second version, recently released, also has a small chapter about AutoMapper included. It's not in the free sample chapters but you might want to check out the source code (or buy the book of course).
If you are using .Net 4.0 then you should definitely consider creating and using POCO Entities instead of EntityObject which is not only gives you Persistence Ignorance (which you have mentioned) but also you will not need any Mapper in between since you work with POCOs (Plain Old CLR Object) in all layers including your data access.
If you haven't work with EF & POCOs, then this would be a good start:
http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx
If you are using .Net 3.5 SP1 and CANNOT upgrade to 4.0 then like XIII correctly mentioned, AutoMapper will automate your mapping process or you can come up with your own AutoMapper which is nothing more than a simple reflection code.
I'm going to be starting a new project with ASP.NET and I would like to use some framework which speed up the process. Recently I have heard that there are two main frameworks in that platform: the MVC and the Entity framework. Are they compatibles? If not, what are your advices on what to use and why? What are they best properties?
You can't compare them. These are 2 different things.
Entity framework is ORM mapper, Asp.Net Mvc is a framework that helps building web applications.
Actually - they even aren't mutually exclusive and you can use them both together quite nicely.
MVC is an architectural pattern to build applications; entity framework is a object relational mapping framework. Quite different animals.
And yes, they can be used together, no problem.
ADO.NET Entity Framework is an object-relational mapping (ORM) framework for the .NET Framework.
http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework
http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx
Other entitty frameworks are -> LINQtoSQL, NHibernate etc.
Model–View–Controller (MVC) is an architectural pattern used in software engineering.
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
http://en.wikipedia.org/wiki/ASP.NET_MVC_Framework
They're different things entirely.
Although they're different things entirely they are compatible. I am using both frameworks on a project now.
You can use both of them into a single project.
Entity framework is object-relational mapping (ORM) framework. It is an
enhancement to ADO.NET that gives developers an automated mechanism
for accessing & storing the data in the database.
Model-View-Controller (MVC) is an architectural pattern that separates
an application into three main logical components: the model, the
view, and the controller.
These are 2 different things as mentioned before.
Entity Framework is an ORM -> a Mapper to help you get data.
asp.net is a framework to STRUCTURE your project ,with Objects and Classes, not related to entity.
We're about to embark on some ASP.NET MVC development and have been using our own entity framework for years. However we need to support more than our entity framework is capable of and so I'd like to get some opinions about using MVC with a more robust framework. We have narrowed down or choices to either NHibernate (with the Fluent APIs) or LINQ to SQL.
Which framework lends itself best to MVC style development (I know SO uses LINQ to SQL)?
If we want to support SQL Server, Oracle, MySQL - does that exclude LINQ to SQL?
As someone who has just switched from LINQ to SQL to (Fluent) NHibernate, here are a few things I've noticed.
LINQ to SQL took so long to figure out how to do the equivalent of a join-subclass. After many modifications, I read somewhere that it is not possible. It can only map inheritance if ALL the columns are in that same table. This is great if there are a few columns, but there are tons in my case and sub classes are parents to other sub classes and so on. Why should I put them all in one table for the sake of my ORM?
NHibernate from experience has been robust (sometimes too much for small quick projects) and although familiar with it through small projects, I felt it might be too much and went the route of LINQ to SQL since I could generate a DBML file and be going within minutes.
Fluent NHibernate. Takes the best of both worlds (in my case). I can map the way I want to and have my database the way I want and not have to compromise in my domain or data models. Also one word: Automapping... icing on the cake.
I would have had to go with another ORM once I found limitations and hit a few road bumps with LINQ to SQL, but Fluent NHibernate made this choice easy, and I don't think I'll leave it unless something comes around that does the job even better.
So, like Rob Scott said, the question is how are you abstracting you domain => data model? And are you starting with a domain or a database? How complex are the relationships? If you have any inheritance at all I'd say just go with a richer ORM framework and save yourself the grief.
Fluent NHibernate has some of the best documentation I've ever found and there are so much support, notes, blogs and resources it's self-hate to do anything less... IMO! I was up and running in less than 24 hours.
Oh and if your'e new to NHibernate pick up the NHibernate in Action book to help grease the wheels although there is a lot of help for that framework as well.
The best indication that a tool isn't working is when you have to WORK the tool... LINQ to SQL I was customizing, reading white papers, all sorts of madness and it refused to generate appropriate queries, right when I was tempted to modify my table and domain, I said let me give Fluent a whirl, and I'm happy I did.
Good luck to you.. Sorry for the long response; this has all been in the past five or so days, so I guess I'm still caught up :-)
I've had great success using Fluent NHibernate and dependency injection (Ninject, in my case) with MVC.
It seems to me though that any mature ORM should work well with MVC. Since the nature of MVC (Model/View/Controller) separates the three concerns, any ORM should fit quite nicely into the "Model" role.
LINQ to SQL is for SQL Server. Entity Framework supports some other databases as well.
NHibernate is good choice. You may use Castle ActiveRecord (it's built on top of NH) if you are doing data based application or Sharp Architecture for project guidance.
Entity Framework integrates nicely with MVC and supports other databases.
The short (and not so helpful) answer is that both of the ORMs you've mentioned will work with MVC. A longer answer is that you should think about how you want to work with your model objects. For example, do you want to do domain object first development (ala a Domain Driven Design approach), or are you implementing a "forms over data" type application where you might want to generate a data access layer from an existing db? What is your preference for specifying mappings? Do you want to use a fluent interface or are you happy with mapping files (or attributes on your domain objects)?
These are the type of questions you need to investigate when choosing an ORM -- and they're mostly independent of whether you're using MVC or Winforms.
Entity Framework makes things complex. Use Fluent NHibernate, with Repository pattern and inversion of control in controllers.
NHibernate will make lots of things easier. We have recently migrated from Entity Framework to Fluent Nhibernate, and Fluent NHibernate is definitely the better candidate.