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.
Related
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.
I am an asp.net webforms developer and new to asp.net MVC....
Is it possible to use SQL Server 2005 stored procedures in asp.net MVC?? If so can any one help me....
This is absolutely possible. Although it claims to be a Model View Controller framework, ASP.NET MVC is really just View Controller, it's up to you the developer to decide and implement a model persistence layer.
As a WebForms developer you're likely familiar with DataSets, however these are usually avoided in an ASP.NET MVC application in favour of an ORM framework like NHibernate or Linq2Sql, both of which have plenty of resources online for integration with ASP.NET MVC. As a good starting point, you might want to look at S#arp Architecture which is a good example of a best practice MVC stack.
Using stored procedures is not directly related to which type of application you are building. You could use the same type of data access code as you are used to from WebForms, such as ADO.NET (SqlConnection, SqlCommand etc.).
Absolutely agree with answers above, my advice is to use Entity framework or LINQ2SQL and simply import stored procedure as function which you can use as dbContext.Somemehto();
Stored procedure should only be linked with Model that is pure sever code, so there is no difference in using it from Desktop application or from Model. If it is not distributed database.
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.
As I am a beginner to ASP.NET MVC, I would like to know what are the best data access methods for ASP.NET MVC?
This is somehow subjective. There's no such thing as best data access method for ASP.NET MVC. This will depend on your application requirements and specific needs. There are many different ORM frameworks you can choose from such as NHibernate, Entity Framework, Linq to SQL, ... (If there was a best framework this list wouldn't be so big).
As ASP.NET MVC is all about TDD and separation of concerns it is more natural to use any type of ORM for data access (NHibernate, Entity Framework, LINQ to SQL etc.). What type of ORM - depends on your project goals and experience.
If you're just learning MVC, and are ok with SQL server, then I would recommend using Linq to SQL for a start. Later you can then introduce more powerful ORM like NHibernate or EF. If you try to tackle MVC and something like NHibernate at once you will likely bite off more than you can chew.
I am in the start up of a project using ASP.NET MVC and have started creating my models. Since I know some Ruby On Rails and would like to use a system as similar to Rails Active Record as possible.
Have anyone used Castle Projects Active Record in a ASP.NET MVC application (or any application that is relevant) and have some experience to share?
Are MVC and Castle Active Record the right way to go or do you suggest I use LinqToSql instead.
Please share any thoughts and experiences you might have gain.
Edit: To clarify; I come from a long ASP.NET and C# background but have looked a little at Rails and love how easy you can create the ORM
I have used Castle Active Record with ASP.NET MVC. I highly encourage this model, as ActiveRecord/NHibernate are much more mature that LINQ to SQL or the Entity Framework.
I think that ASP.NET MVC has a bright future and would recommend it over Monorail for new projects. However, as I said, ActiveRecord is (in my view) a superior ORM to LinqToSQL.
Coming from a Rails background, Castle Project AR will feel closer to what you're used to, but Linq to SQL is better integrated with the whole Microsoft ecosystem and you may find this is worth the extra effort to learn it.
Linq to SQL has some major missing pieces, notable many to many relationships. If you're going the "pure" Microsoft route look at .net 3.5 sp1 and Linq to Entities, which uses the new ADO.net Entity Framework.
I've used the Castle ActiveRecord with MonoRail and it is fairly easy to use and intuitive, although the innevitable problems you'll come across are often hard to diagnose. Its documentation is also not the best (as with many open source projects). By default it uses NHibernate ORM underneath, and if you were specifically after using an ORM framework I believe there has been some effort to support LINQ with NHibernate, no idea how far it is along though.
I think it also depends on the size of the application, if its a quick project that won't necessarily be maintained heavily then the ease-of-use ActiveRecord gives might be handy, but then LINQ also seems pretty easy and neat. If it was a larger application I would consider rolling your own data layer using NHibernate, again if its specifically the ORM you want.
Do you need the ORM to be free (as in beer)/open source?
If you don't then I would highly recommend eXpress Persistent Objects from DevExpress.
If not, then I dont think LINQ is similar, I haven't used ActiveRecord from Castle but I guess that's the most similar to RoR
MVC doesn't know what ORM you are using, or is there even some ORM tool behind. Controller/Action must send object references to View, so that object can be simple int, string array, DataSet, Linq object, ActiveRecord object, whatever, it doesn't matter for View how some object is filled with data!
Prefer NHibernate as your persistence layer.