The question is in the title.
It doesn't favor one over the other at all. It's just common to use LINQ to SQL examples because they are simpler to setup and deploy, so it's easier to digest the sample code without getting distracted by something which deserves its own learning path.
I agree that it does not favor one over the other. I always assumed that Linq to SQL tended to be used in examples because it was released about a year earlier. Therefore, book writers were more familiar with Linq to SQL and/or felt it was more stable.
I agree with Rex in that it makes more sense, when giving a tutorial about ASP.NET MVC, to keep other technology decisions simple. Since either DAL implementation can be used, it is easiest to teach MVC by using Linq to SQL (the simpler of the two). Linq to SQL is also widely considered to be more light-weight.
I must admit, it would be nice to have more open-source examples of projects using ASP.NET MVC along with Entity Framework. I can tell you that it works fine, because I am using it on one project. However, it can be a bit more difficult to figure out some of the ideosyncrasies. Here is another question that shows some links to examples.
I think this tendency to use the path of least resistance in example is a diservice to new developers. How many times have you seen an example, with the caveat that it is not production worthy code, with no reason as to why it is not appropriate, or good direction on how to find what is best? Personally, I appreciate longer examples that actually lead me to discover how something should be used are more helpful.
In this particular case, using Linq to Entities would be much more useful, as it is seemingly the future.
In my opinion, it doesn't favor it. It's what you see in most examples, because Linq to Sql is the fastest way to get examples up and running. Rails follows the same convention of many examples using features (scaffolding for example) that you would rarely see used in a production site.
As all the other posters have said - L2S samples are just a lot easier to put together hence you'll see them quoted more. In reality your MVC models may not use L2S directly - they could be hooking up to a separate services tier or some data transfer objects exposed by another system entirely.
Related
I've been seeing a lot of articles and references about how to use this patterns for my first (please keep this in mind) serious project with ASP.NET MVC 3 and EF.
The project is not so big (13 tables) and it's basically a CRUD maintenance: organisations that have some users; users that can belong to a group and can create some work areas and templates... Nothing complicated. The point is that this will be the first of a project series and I'd like to create a base to work with.
My questions are:
Which of the previous patterns is the best? Does it depend of the project size?
My models would be these:
Unit of work
Dependency Injection
Do you think they are good enough and appropriate for my project?
I appreciate all your comments.
Serious application doesn't mean to be complex at first sight.
Over engineering an application upfront can be a real disaster, especially if you don't grasp all the technologies involved.
My advice would be to keep it simple. Create a basic application that fulfill requirements (get the thing done and make your boss happy) and then add new concepts along your learning path.
That doesn't mean I promote bad code, no way! Keep your code clean, well organized, etc. But don't be killed by the fear of doing something wrong.
It's normal for a developer to look back to an application made a few weeks ago and then realize that he did some shitty stuff. That's how we progress!
Last but not least, have FUN!
ASP.NET website provides usefull resources to learn the framework and all related guidances. There are a few application samples created step-by-step.
ASP.NET MVC was built with Dependency Injection in mind.
If you want to give a chance to your code to be loosely coupled and easier to change in the future you have to follow the patterns like Dependency Injection, Repository (for presistance abstraction), and UoW (for transaction abstraction).
So my answer is, you should learn about them in the first place to decide after if you want or no to follow the best practices. Even for simple project it's good to apply these patterns because often it gets bigger and bigger. and it's easy to do it in MVC so why to avoid it ?
There is many resources around to learn about. You can just google it.
I would like to answer this question in more generic way. Creating something which can be used in future is difficult than what it seems. All the pattern above can provide you infrastructure pieces to come up with some base framework.
But I would strongly suggest you to look at S.O.L.I.D principals (DI being part of it) to understand some qualities of good code. These are applicable irrespective of the technology involved.
You cannot predict the future requirement of a product\framework, but following these principle you can be better prepare to handle any future modification to the software
You might want to check out S#arp Lite which has many good examples of how to implement the things you want and can serve as a very good base on which to build something quickly.
None of the mentioned patterns are mutually exclusive. You should use the patterns that make sense based on what you are trying to accomplish, not attempt to shoehorn your application design into someone elses idea of how it should work. Sometimes trying to bend your scenario to fit a particular design pattern / practice is the worst thing you can do.
Want to make sure good unit test coverage / do TDD / ensure loose coupling? Then Dependency injection is your friend, as is the Unit of Work pattern. This is definitely a good idea for creating a maintainable, scalable application, but you can go too far with it for a small-scale application.
Need a centralized caching strategy for your data source? Then use the repository pattern. Or an ORM like NHibernate, which might do it for you.
At the moment I have a fairly big website with about 10k visitors a day.
This is a community website with news/blogs/videos and a big forum.
This all runs on a self made PHP5 application which performance faily well, has good performance. The database is a MySQL5.1 database.
Now I am getting fedup with PHP and the loose typed framework, lack of namespacing and a proper MVC setup, so I am thinking of rewriting the site in MVC3 ASP.NET.
Now I have experience with this, but not in the MVC framework yet, and I have a few questions about the performance, especially the Entity Framework:
Is it even worth using the entity framework? Will it cost alot of overhead and performance degration? I am not sure yet if I should switch to MSSQL.
Entity Framework was not performance optimized as far as i have worked with it. That is not it's primary goal by design. Performance is important of course, but EF is at most easy to use, and start with. It provides an fast way integrate with existing database, or create database really, really fast. Performance is not the primary goal, but improving indeed.
Here is an good chart with some benchmarks from the Microsoft team, that can be a ground for making the decision.
As you can see, there is a dramatic performance improvement from .NET 4.0 to 4.5 as far as it comes to "LINQ to Entities". It still seems twice slower than direct SQL though. LINQ to SQL is the slowest operation of course.
ASP.NET MVC is an good direction, especially if you want to try something different. EF is not the best you can do if you pursue performance. Writing the business layer on your own, including the SQL stored procedures would be better, but will require a lot more time.
When using an ORM like EF or NHibernate you always have to live with the trade-off between performance and convenience. If you can live with a relatively bad performance (I think it should be possible to run your site w/ an ORM) NHibernate should your first choice, from my point of view it is more mature while EF is still lacking provider support and has some shortcomings with respect to the develevopment workflow (which you possibly expect when using NHibernate but not when using a MS tool).
If you switch from PHP to .NET you should consider switching from MySQL to MSSQL, just because it fits perfectly into the MS ecosystem (and performance/scalability should be improved too, this could possibly outweight the performance degradation you expierence when using an ERM).
You could also take a look at LINQ which could be an alternative between a classic ORM and hard coded SQL commands (also with respect to the performance, LINQ to SQL is pretty fast and you can also use LINQ to Entitiy Framework when using EF (thats pretty slow)). LINQ would fit your needs if you want some level of abstraction wihtout the need of endless configuration and if you like RAD (who doesn't?).
In general the performance of ASP.NET MVC3 is quite good, but you should know that you need some experience to tweak your application and avoid (common) pitfalls. Cutting a long story short: You should be easily able to write an ASP.NET application that has a better performance than a scripted PHP page (by design)
But you should also know, if you decide to commit yourself to the MS ecosystem (.NET, MSSQL w/ LINQ/EF) its hard to break out and providers for LINQ and EF for non-MS RDBMS might cost some bucks (check www.devart.com).
Hope this gives you some guidance
Further reading:
ORM wars: Comparing nHibernate, LINQ To SQL & the Entity Framework
NHibernate vs Entity Framework: a performance test
NHibernate vs. Entity Framework 4.0
This is way too much of a general question, and there's no good answer to it. I highly recommend that you perform some tests using the Entity Framework as well as MVC3 and see that it meets your needs.
Also, and not to be condescending, but 10K visitors a day is not that much compared to other sites out there that are succesfully running ASP.NET MVC and Entity Framework.
In the end, I'd say it most definitely will meet your needs, but as with any project that scales, you will have to be aware of bottlenecks in your particular app and come up with solutions to address those bottlenecks.
This is 100% dependent on the queries.
I've worked on sites with 22 million a month with Nhibernate and about 10 million a month with Linq to Sql.
The queries that performed the slowest were always those weird aggregate quintuple join monsters. ORMs get you 95% of the way there. The rest you'll have to optimize. No ORM gets SELECT * FROM table wrong. Its the outliers that matter.
This will probably get closed as subjective/argumentative in the next five minutes, but I'll give it a shot:
You'll hear a lot of differing views regarding EF and other ORMs, but my personal view is that they cause more problems than they solve. Queries should be kept in the database, where they belong. Proper separation of concerns (SQL code in the database, app code in the project) saves you a lot of problems long-term.
Think of it this way: if your queries were all in stored procedures, you wouldn't even be thinking about migrating/rewriting them at this stage. You could focus on implementing the web side of your app instead of worrying about how to transition your SQL code.
So, skip EF for now, focus on what you know.
I have learned the language itself as well as html/css/javascript. But with no database knowledge and (a bit)network knowledge. When I read the Pragmatic book on ROR, I found it confusing at the very beginning where they creates a project and setting up databases and models. Should I learn some database(and network knowledge)knowledge first in order to fully understanding the code and to fully grasp rails? If so, points out some book suited for these subject. Thanks in advance.
sorry for my bad english..
Unless you're doing network specific stuff, all you need to know concerning networking is a basic understanding of how the HTTP protocol works.
Models have nothing to do with databases per se, they're just regular classes in your language, that happen to map to a database table in Object Relational Mapping (ORM) type frameworks such as Rails.
You can view them as the gateway to your database.
The database you'll be using is most likely a relational database. You don't need to know much about the theory, but you can get a very basic overview on wikipedia.
Probably the thing you'd need the most is a basic understanding of SQL, although the point of an ORM is to abstract that SQL away. You'll see glimpse of it when you look at the log file where you see the actual database queries. And when you get to more complicated, specific stuff, you might need some SQL.
In any case, you'll need general knowledge about databases and SQL in pretty much any type of development.
The short answer is YES. Even though ActiveRecord abstracts away much of the dirty work with the database, it is still important to understand what is going on. It will be useful, sometimes vital, when debugging, deploying, and/or maintaining.
You almost certainly will need some general understanding of SQL to work with RoR (and as others have said, probably for programming itself).
I'm a fan of the book Simple SQL. It covers SQL generically, as much as it can. That is, it goes over the basics of SQL itself rather than the details of one or the other SQL implementation. Also, the majority of the examples are web related which should fit you well.
I'd agree that a basic (at least) understanding of SQL is essential when doing any sort of database work. I found the "Sams Teach Yourself SQL in 24 Hours" book helpful when i first started dipping into database work. It covers pretty much everything you need to get you started.
My advice would be to pick a DB (MySQL, Sqlite, MsSQL etc.), learn some of the basics for that particular DB (i found it useful to know how to create new users and set permissions), learn some generic SQL and really get to know what ActiveRecord can and can't do.
Hope this helps a little.
What is really important is to understand the concept of MVC (model view controller)
I recommend you reading this getting started guide
RailsGuides in general are really helpful and more condensed than the book. You might prefer it
(source: rubyonrails.org)
I am starting a new ASP.Net MVC project and was wondering what is the best Model approach to take.
Most demos recommend LinqToSQL but I know Microsoft are not really enhancing this product and are focusing more on the Entity Framework.
I like the Subsonic approach but I thought this was going to be built in with MVC with version 3 but there has been no news about the development stage of this project so I am a bit wary of using version 2 if there is to be a new release soon.
I have heard of NHibernate and Castle Record but have not had any experience at all with these and have heard numerous pros/cons for both.
Any help would be highly recommended!
nHibernate learning curve is higher but worth it. Use Fluent nHibernate to ease the pain a bit. nHibernate is less visual that some ORMs but that is really only an issue when you are beginning and once you have experience with it the lack of visual designer is a benefit IMO.
For SubSonic, Rob just release an new MVC template which you can use when starting a new project that bakes a lot of good stuff into a new MVC project including a pre-release of SubSonic 3. Detais are available on Rob Conery's blog.
LLBLGenPro works great for me. It is the best .net ORM out there. I'd avoid Linq to Sql because you'll have problems once the project grows and it is rather weak in features (besides the obvious downsides, like works only with SQL Server, etc.)
I use linq2sql and I think it works absolutely great if you use MSSQL as your database (it works on other databases too, but it requires some 3rd party tools). Yes, Microsoft has 'discontinued' its development, but it is mature enough for the average project. I doubt you will run into any walls. If you're starting a big project that you need to support for years to come, then the Entity Framework might be more suitable.
I personally haven't used NHibernate and Subsonic before, but like Craig says, the learning curve of NHibernate is a bit more steep, though it is supposed to be a great framework (everything from what I heard or read).
If you're willing to spend some money or have a smaller project I'd at least try out LightSpeed. I found pain points withe very ORM I've ever tried and I'm currently using LINQ to SQL myself.
LightSpeed is pretty feature rich though the LINQ support is missing a few features nothing major that can't be worked around. It's pretty close to being the same as LINQ to SQL and LINQ to Entities but has a few more features like Full-text Search.
Castle ActiveRecord works really well for small-to-medium projects based on MVC - I'm using it on a couple of projects at the moment and finding it a very good fit with ASP.NET MVC.
It's an implementation of the active record pattern that uses NHibernate under the hood - in other words, as long as you're happy having one class per database table, it'll do most of the NHibernate configuration for you, leaving you free to write code like:
Customer bob = Customer.Find(/* customer Id goes here */);
bob.FirstName = "Robert";
bob.Save();
Invoice newInvoice = new Invoice();
newInvoice.Products.Add(Product.Find(/* product ID goes here */);
bob.Invoices.Add(newInvoice);
bob.Save();
with very little explicit NHibernate configuration (assuming you have Customer, Invoice and Product tables in your DB, of course)
Because it's NHibernate under the hood, migrating to NHibernate if you need to should be straightforward - you'll already have all the necessary references and libraries. There are a few aspects of NHibernate behaviour that you can't ignore (like session scopes and flushing) - but it's not too hard to work out what's going on with these, and using them in ActiveRecord will give you a head start if/when you need to move to using NHibernate directly.
We're using Fluent + NHibernate here, it works pretty well. Some alternatives that mesh well are SubSonic, Entity Framework, and Linq to SQL. I think straight NHibernate is a bit more cumbersome than it is worth, but is a great underlying layer with Castle ActiveRecord, and with Fluent.
I worked with a product called netTiers (http://www.nettiers.com/) on a project and that worked very well. It's a CodeSmith script that generates business objects from your database tables, views and stored procedures.
If it's not a huge project, I'd use Linq To SQL. If you need all the bells and whistles, bone up on nHibernate and have at it. I don't think you'd run in to any serious issues one way or the other.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
update: I know there is no one best way to do everything. Sorry for not saying that right off. In the context of the data-access tutorials, if you had to do the project he did in that tutorial, would you do what he did or would use use MVC, if you had to choose one of them?
Update: Is MVC the more appropriate way to program asp.net applications, instead of the tutorials found here:
http://www.asp.net/Learn/data-access/
Original:
I ask, because I initially learned about MVC with Java applications, then things like RoR, and Django. These other projects and companies spoke as if MVC had been around for a very long time, and from what I found out it had. Then Microsoft started putting MVC into the .net framework.
I ask because I don't know how to design things very well and thought I was doing well to emulate what's on the asp.net site with Scott Mitchell's tutorial. I thought that creating abstract layers in a BLL was the way to go until I found out about MVC and now asp.net's MVC.
I honestly don't know what the "right" way is to do things. I just create what I need, but I can't help feel like I am missing something.
Is MVC the correct way to start doing things in large projects, specifically I mean MVC and ASP.NET, but could just as well mean PHP and one of their MVC frameworks.
I'd like to settle on a standard way of doing things...for now anyway.
And, out of curiosity, why did Microsoft only now start doing MVC?
UPDATE: Is MVC better than the current tutorial set on asp.net?
I'm referring to the Scott Mitchell tutorials where he creates the BLL for abstraction. Or is that a linq question as well. I should have said that I understand the need for keeping logic and presentation separate but unsure the best way to do it. I was using the asp.net tutorials. It worked fine. Then I found out the rest of the world, as I saw it anyway, was using MVC. Then Microsoft started developing MVC, so to me the other method seems obsolete and the wrong way to do things.
No, it's not the only best way to do things.
MVC is just a design pattern. The goal of all design patterns is simplicity. So as long as it makes your design simpler, go with it. If it makes things more complex for your specific application, try a different approach.
Unfortunately, some people think if they see a pattern, they should use it. It's just not true. Design patterns don't inherently make your application better. They are not an end. They are a means to an end (which is simplicity). So you should use them only if they are worth it.
In my opinion, over-architecting things without a good reason is worse than writing code without any specific design.
EDIT: Regarding ASP.NET MVC: I have a negative personal bias toward ASP.NET Web forms. Before MVC, I did most of the dynamic aspects of advanced projects by writing custom handlers to have fine grained control over the HTML. Web Forms make Web development very easy but they have particularly a couple things that are good but sometimes are problematic. The first of which is ViewState and the second is complex WebControl architecture. Don't get me wrong. Those are signs of brilliance of ASP.NET. I haven't seen a single platform for Web development as easy as ASP.NET Web Forms and this is only because of great WebControl support which requires ViewState. However, in some projects, you want to have precise control on rendered HTML (specially when you have some client-side logic). You also want to make server side code maintainable in large projects. In those areas, ASP.NET MVC really shines. But I think ASP.NET Web Forms will remain a great technology where it's more applicable. After all, as I said regarding design patterns in general, you should carefully evaluate your design to see which one better fits your needs.
Specifically, about data access, MVC usually requires more code than Web Forms counterparts. For presenting tabular data (i.e where GridView is applicable), I think ASP.NET Web Forms is the easier way to accomplish things. However, most data driven Web apps are not just manipulating a table directly in a database. They have complex layout. StackOverflow is a great example of this. It is certainly data driven, but ASP.NET MVC better suits it.
There is no "right" way to do things without knowing what "things" are. MVC is a design pattern that solves a specific common problem - separation of presentational and domain logic. Every design pattern is a commonly accepted "good" solution to a specific problem.
Those solutions, combined with knowledge and experience are building blocks for a good design. The "right" way to do things is to study your problem domain, research on possible solutions and apply the set of solutions that work best to solve it. Making mistakes is a part of the process as well, so don't be afraid to experiment and then refactor with rigor until you reach the solution that serves you best.
MVC is the worst way to develop applications, except for all other ways that have been tried. :-)
Joking aside, MVC is one application design that encourages us not to write spaghetti code. It's a guideline that reminds us to keep business code separate from presentation code. This is very helpful as the application gets more complex.
There are other variations that achieve that same benefit, but are not strictly the same as MVC. Presentation-abstraction-control (PAC) is one example.
As for why Microsoft is so late in adopting MVC, I'm not surprised that they are. They are pretty well-known (at least in recent years) for being conservative instead of innovative. They prefer to let other smaller companies take the risks in an unproven market, then they learn from the mistakes, churn out an overengineered competitor solution, and dominate through marketing.
Example: Microsoft Internet Explorer was considered to be a latecomer to the browser market. Netscape had become very popular, leading the way in providing a platform for people to view HTML. Once the amount of HTML content on the Internet was at a useful level, Microsoft belched up their onomatopoeic "IE" product and quickly captured an overwhelming market share.
MVC is just one way of doing things. I like it because it helps to promote extensibility and is structured to allow testing and code reuse. There is no silver bullet, one true way to do everything but I use it quite often.
In regard to Microsoft, I would say that they adopted the pattern as an alternative to WebForms development for the reasons I mentioned above. I would recommend looking at Rob Conery's MVC Storefront and kind of play around with the examples to see how it works for you.
There is no "best" way to code things. It depends on the application in question; sometimes MVC is the right choice, and sometimes it's not. A good developer is able to weigh his/her options and choose the one that's best suited for a task at hand, instead of just going with the method du jour
If MVC solves the Primary Technical Imperative of managing complexity in your application then it may be a good solution, but it is by no means the only solution.
MVC is one of any number of design patterns. Whether it's the best technologically, or the simplest, or for what types of projects it's appropriate, are are all arguable (see other SO threads). In any case, few would argue against the prevailing consensus that for most cases, it's "Good Enough".
But it has the undeniable benefit that a lot of people use it, on a lot of different platforms.
So if you want to use a methodology that is likely to be around a while; or you don't want to depend on one vendor for support and extension and refinement; or you work in a group that would like to grow by hiring people from various backgrounds who will grok a shared methodology quickly; or you would like to maximize your opportunities to move on if you need to, then MVC is one of the very best ways to support those goals.
MVC being "Better" or "Worse" pattern is relative to the project.