I am planning to start learning asp.net mvc. And also I want to learn Microsoft's Data Access application block. But I dont want to waste time in MDAC block if theres a better option to go for, or if MVC provides any good feature than MDAC. As I have heard MVC architecture automatically generates code.
So, please guide me regarding this. Thanks in advance.
It's not part of MVC per se, but I'd recommend using LINQ to SQL or LINQ to Entities (Entity Framework) over the Data Access application block if you're interested in a pure MS object relational mapping. You could also look at nHibernate or a variety of other ORMs to accomplish this. Any of these would suffice as the basis for the M(odel) in an MVC application.
Try the Nerddinner example application, there is also the data access included. The tutorials are extensive: http://www.asp.net/mvc/learn/
Don't work with MDAC block if you are not forced to! Try NHibernate, Entity-Framework or LINQ instead.
Related
I am creating a web portal on real estate. I am building it on ASP.NET MVC 5. For database connectivity, should I use Entity framework or not? and why? If not then what should I use? (I was using normal sqlclient method when I was working on web forms).
Updating for more clarity :
I am having very complex query scenarios in my project such as I have to search n various filters etc. I am also using angular ajax for many features. Now can anyone suggest either go with EF or not?? Thanks
Use an ORM (like Entity Framework) because it will read data from a database and give you back some easy to use classes, manage change tracking, allow easy updates, etc, etc. These two articles may help as they list of ORMs and contain some performance data:
Fetch performance of various .NET ORM / Data-access frameworks
Fetch performance of various .NET ORM / Data-access frameworks, part 2
Also you may want to take a look at this Stackoverflow question:
Are there good reasons not to use an ORM?
There are several infrastructures designed to help you create websites using ASP.NET. The EntityFramework, which is part of ADO.NET, help you do ORM, MVC 5 is, well, for MVC. There are others, like Razor.
All in all, it seems fine to use EF for DB connectivity and ORM, as it seems to be the standard.
I need to write a forum application for a friend's web site. I want to write it in C# 3.0 against the ASP.NET MVC framework, with SQL Server database.
So, I've two questions:
Should I use Linq to SQL or the Entity Framework as a database abstraction?
Should I use the ASP.NET Membership API or add Users table and implement it myself?
Thanks.
There are lots of examples around internet which is using ling with ASP.NET MVC. But may be you can add your list NHibernate. If you do not want to add i suggest Entity Framework. Using ORM's is a plus.
I always chose write my own membership management layer. If you are a person like (write your own code and be happy when you are making changes in future.) write your own membership layer. If you are looking for a quick solution ASP.NET Membership API is a good choice.
Entity Framework definitely -- see below.
ASP.net Membership API -- easy to maintain.
Reason:
Entity Framework vs LINQ to SQL
1) How about both? Just create an abstraction and you could just use either. My recommendation is to use the repository pattern.
2) The membership provider has its strengths and weaknesses. For some projects, it was far too complex for my needs. However, it is great if you need to get something running in a short amount of time.
I won't answer the first question since i'm a fan of nhibernate
for the second question adding a users table and implement membership yourself i don't think you will be able to do it at least the right way (lot of people tried to make their own membership api but they messed up !)
1) Totally depends on how complex things are going to get. If you want a quick DAL that more or less mirrors your tables in a 1:1 fashion, go for L2S (or SubSonic if you want something more mature and supported). If you are going for more of an n-tier type thing where your tables and domain model are completely different, go for an OR/M like Entity Framework (or NHibernate if you want something that is pretty much better in every way)
2) ASP.net Membership is extremely complex, and there are bits of it that are fairly poorly engineered. However, it depends on how much experience you have with these things. If you enough to know how to take steps to avoid session fixation attacks, just roll your own because chances are it will be better then the canned solution. If you have no idea what that is, take the time to learn the default one.
Something to think about, SubSonic 3 is a pretty powerful data access generation tool. From what I understand, it basically wraps Linq to Sql inside of some very useful wrappers and makes using Linq a little more intutive. You can have a pretty powerful application built up in no time flat when using SubSonic. One little issue though, if you're using a shared hosting (say GoDaddy) you'll run into a medium trust issue. In that case you can always fall back to Linq To Sql without making many changes to your code base.
As for Aspnet_Membership. Just for the amount of tools it provides, I'd reccomend using it.
Good luck, and hope this helps.
I have an asp.net mvc application and i need to connecto to the DB i have saw a tutorial video that connect to DB using wizard by adding DB connection and determine the DB and add a model but i need to know if i can use connection string and query the DB or calling procedures in DB ???
I need any tutorials or step by step article that describe how to connect to DB without wizard and call procedures and query tables.
Thanks in advance and i am a begineer in MVC
I hesitate to respond to this, but EVERY video you have seen is likely using an OR/M to generate the Model and the DAL. The generated DAL will likely encapsulate your calls to the stored procedures that you're asking about.
The thing is -- and here's why you're not getting the answer you're looking for -- each OR/M is going to have a different method of retrieving data from and inserting data into the database. How you retrieve data from the DB using an OR/M is going to be different if you're using Entity Framework, Linq to SQL, SubSonic, NHibernate, or any other OR/M.
So, the question is to you. Are you using a OR/M? If so, which one? If not, then you will use the standard ADO.NET calls to retrieve and store data. This is also reflected in my comment to your original question.
Yes you can (google ado.net for tutorials on ado.net), but it's not the MVC way. The MVC way is to use some sort of ORM (Object-relational mapping) such as NHibernate, Subsonic or Linq for SQL.
how to connect to DB without wizard and call procedures and query tables.
To call a procedure (here it will return no result, just perform some action):
using (SqlConnection connection = new SqlConnection(connectionString))
{
connection .Open();
using(SqlCommand command = connection.CreateCommand(nameofthestoredprocedure))
{
command.CommandType = CommandType.StoredProcedure;
command.Parameters.AddWithValue("#someparameter", somevalue);
maCommande.ExecuteNonQuery();
}
}
You can put your connection string in the config, just like you're used to.
You can call procedures the same way you would from any .Net application too. #svinto's advice about using an ORM is another way of doing things and is well worth looking at too. Many of the good examples for ASP.Net MVC use the ORM techniques.
If you don't want to go down that route, you might benefit from creating a seperate class library project that you reference from your MVC application. Your Class Library project can act as your data access layer (DAL) where you handle db calls, etc...
Your Controllers can then call your DAL and processing methods to populate entities for the Views.
Ahmy, I think the best advice to give would be before you start off developing using the MVC framework is to have a look into the principles behind the MVC pattern and domain driven design.
Specifically , have a look at repository patterns etc.
You can still add connection strings to your web.config in a block and access them as you would have done in a webforms project, after all Asp.net MVC is based on webforms. Its just likely that you wouldn't really want to do this if you're utilising MVC the way it was intended, its all about seperation of concerns.
www.asp.net has some great intro. examples worth watching.
Try downloading NerdDinner, or even better ... ContactManager iteration 1 (the tutorial directly answers your Q). Those should give you a good idea for how to handle database access. I wouldn't suggest looking at something like Oxite or MS StoreFront though, as these are a bit more complex.
To specifically answer your question: the connection string, like in ASP.NET, can go in your web.config or hard-coded in your application.
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.
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.