Let's say we are developing an E-Commerce Web application for a small to medium sized business. Let's further assume that the business is likely to scale over time. In other words, the product line will typically grow.
Up to now I have developed n-tier solutions using ADO.NET and stored procedures with the help of the SqlHelper class. For bigger applications I have used Enterprise Library (2.0).
I would like to move towards an ORM-based approach and am starting to learn LINQ as well as making the switch from ASP.NET Web Forms to ASP.NET MVC. I do not want to go with LINQ-to-SQL. The question is not whether an ORM is required but if the Entity Framework ORM is overkill for such a project. I don't mind a learning curve if it is warranted for the task in hand.
As regards "overkill", I would like to know if:
EF is faster than someone with the correct skills coding queries manually
EF leads to unnecessary code bloat
EF unnecessarily shields devs from code-level details of their queries
LINQ-to-Entities is suited for projects of this size
In fact, if anyone thinks that an ORM is overkill for such project I'd like to hear reasons why.
EF is not overkill for web apps.
I disagree with a lot of what is stated in your referenced article. I do agree devs should have decent skills with SQL BUT ORMS do a great job in getting a devs job done more quickly.
Speed of ORMS - They are getting
better all the time & they allow you
to call SP's or modify the queries to
get max speed when necessary. There are also great profilers out there for monitoring ORM performance like EFProf.
Slows down the coding process -
Really!!! Once learned it speeds it
up.
Devs needing to know SQL - I agree.
However, ORMS especially with LINQ
syntax often allow devs to write more
complex SQL than they would have on
their own.
Devs write efficient queries already - REALLLYYYY!!!! Just ask the DBA his/her thoughts! I happen to think I do but so does everyone else. See the problem. :-)
Code Bloat - Have to disagree, especially with ones that have LINQ.... It often makes the code more readable and reduces the line count often.
Forget about LINQ - This ship has
sailed. LINQ Rocks!!!! Go with it or
be left behind. It's not just used in ORMS. It can be used against, arrays, objects, XML, files, twitter and the list goes on and on.... Get to know LINQ.
The article talks about some of the inspiration of the latest developments out of MS as coming from Ruby on Rails. ROR has an ORM based on Active Record in it.....
ORMS are good. They don't have to be used everywhere and everytime but they are good and should be considered.
Although this is a general answer be wary of any opinion which has these comments in:
"X tool stinks, I write in Y tool and I can do it faster than in X tool."
Or course a Latin speaker speaks better in Latin.
EF has a learning curve, but anything new does. EF is not overkill, but as per any system being written use the right technology for the right project.
Looking at the article, the first thing I would see and disagree with is this:
I strongly believe that modern web
developers should:
•Love databases.
•Write highly efficient queries.
•Minimize code.
•Design self-evident user interfaces.
•Work quickly.
I am not sure how many people view web development, but in my mind a web devloper should focus on functionality and business rules. The pure database and SQL code should never be done by someone on my team that would be more productive writing business functional code.
This is where Entity Framework comes into play. It is considered a Rapid Application Development tool (as are most other ORMs). These tools are built specifically to allow you to focus more on how to fulfill the user requirements and less on what the right way to write a query is.
With that being said, I would also say that using the tool naively could be dangerous. When you use Entity Framework you still have to be cognizant of the implications of using the object graph that you are requesting.
It is by far not overkill, the tool is very simple to use and simple to learn. I would argue that it is easier to "fix" an Entity Framework rather than fixing a raw SQL Query and ADO transaction set.
On smaller projects my base recommendation is almost always go with some type of ORM. On enterprise applications you have to be a bit more careful and it entirely depends on budget :-).
An ORM can be quite useful, if used properly and you understand what it's doing for you. You should definitely use one, if you already have some understanding of database design and querying.
The point of the article, primarily, is that the concept of not having to learn anything about database design and querying somehow makes your life better is a fallacy. I prefer very thin layers of abstraction between code and database - I feel that lets me focus more on good user experience.
I personally feel the press behind EF is encouraging new coders to ignore some necessary basics. I've worked with some of them, and think they were done a disservice.
Of course, there are those that will very strongly disagree. No problem!
I know developers who started off loving it, and now don't. But I also know developers that love EF and swear by it.
I've used EF, LINQ to SQL and NHibernate and others over the years.
Best advice: give it a try. Come to your own conclusion.
(Disclosure: I'm the writer of the article you cited).
Definetely not an overkill. Go ahead and use EF.
It actually depends on the complexity of your data model rather than the type of application it is.
If you have a relatively simple data model, then EF may be overkill (if you don't know it yet). Linq-to-SQL may be a better choice (less learning curve, though it also has limitations such as no many-to-many mappings).
If your data model is more normalized, rather than just table based then EF will definitely pay off in the long run, or nHibernate, or any other more advanced ORM.
The article you link to seems to indicate that ORMs in general are bad, not just EF. When confronted on his points, he seems to back off them to some degree. It seems like he is trying to justify a blanket concept (that new developers should have to learn low level coding, particularly SQL, before going to high level frameworks) by inventing questionable points.
Related
I've been trying to write an open-source profile provider to work against PostgreSQL (I was frustrated with the limitations and incompleteness in the other projects I'd seen available), but the documentation and examples of how people use it was surprisingly sparse. Even the SO tag for asp.net-profiles has a little over 100 questions associated.
The more I dig in to making it work, the less and less practical it seems; the value added does not seem to justify the complications associated; additionally, it only seems to work on a limited scope of web projects without a bunch of extra work.
I feel like I'm being led to the conclusion that it is not a popular technology, and that there are better ways to persist a more robust user-based information set.
Is my take on this fundamentally flawed? Is this widely used? I'm on the cusp of abandoning my profile provider as it seems to offer little of value.
I have always eschewed the ASP .NET Membership provider in favor of a custom implementation of IPrincipal for one simple reason. I've almost never needed the out-of-the-box functionality it provides.
Any custom implementation means creating your own implementation of MembershipProvider. Amongst other methods that I have never implemented, it includes wonders like RequiresQuestionAndAnswer and MaxInvalidPasswordAttempts. It forces an implementation upon you that you might not need and will take you more time to complete properly.
Sure, you could cheat and put a NotImplementedException in methods that you're not particularly bothered about, but what right-minded coder would feel comfortable with that in a production system? :D
I really like a lot of Microsoft's stuff, but my experience is that a lot of their "out-of-the-box" solutions are fine in vanilla mode, but the wheels tend to come off when you travel off the beaten path. A bit of cherry-picking is therefore required. My advice? Leave this one on the vine.
No, the Profile system in asp.net is not widely used, primarily because of the reasons you mention. It's just not useful for a lot of people.
The easiest solution is to simply create a profile table in your app, then key it on the ProviderUserkey of the Membership system.
I would like to know the best practice for a designing a simple CRUD application with some screens updating various tables (like admin pages to maintain static data for an application). the simplest way would be to drag a data grid/gridview, bind it to a dataset and use a data adapter for CRUD operations. but if this application needs to be scalable, lets say to add any extra UI/business logic in future, then is there any design pattern that can help with this? should I be using an object data source control and bind it to business objects instead? or are there any better ways of doing it? should I build a complete layered application or will that be overengineering for this requirement? any examples for UI design would also be helpful. thanks.
If you are looking for a really quick and easy approach, you can look at using Dynamic Data
http://www.asp.net/dynamicdata
on top of a Linq2SQL or EF4 backend - hardly any code needed at all.
+1 Oded. No offence RKP but you might be confusing "simple" with with "effective" or "value-for-money". I also think you might want to be more clear about exactly what it is you're after: example UI designs is quite a different issue from the logical architecture. Anyway - good on you for asking.
If this is a "tactical" solution: not expected to have a long life-span, or is a quick-and-dirty dev tool then how you build it might not be such a big issue. (also beware that short-term tactical apps can end-ed being long-term strategic ones - were working on an app now that the business see as a "temporrary" tool: they see it only being used for the next 5-10 years (!)).
If it's a tool the "business users" will use, then it's quite likely they'll expect changes overtime: depending on what the app is for a simple pass-through CRUD app might only cut the mustard for a short while.
So I guess this is where your admirable desire to look at best practice comes in.
Are you familiar with OO design? A lot of the principles behind good OO design also apply at the architectural level (SOLID, Common Reuse, Common Closure, Loose Coupling, Stable Dependancies and Stable Abstraction Principles).
lets say to add any extra UI/business
logic in future
So - this is where you need to consider up-front how you will seperate concerns and allow for growth: architecture doesn't mean you have to do a big upfront design, it just means you need to have an idea of how you'll grow the application as requirements grow..
To finish:
Have a good look at the different system quality attributes and work out which ones are particularly relevant to the system. prioritise them.
I get a lot of mileage out of Dependency Inversion (The D in SOLID) - abstract out things like data access early on.
For me the other really key "best practice" is to pay attention to SRP (the S in SOLID),
http://www.asp.net/mvc is my bet. It's easy to start with and get going... You won't be dissapointed. :) StackOverflow itself is built on top of it.
I am working on architecture of mid sized web application & for my DAL layer i am having 3 options
1) Traditional Stored proc Based Architecture (Using NTiers Template of Codesmith)
2) LINQ To SQL (or PLINQO Template of codesmith)
3) LINQ To Entity
From above LINQ to Entity is out of reach as we need to start application very quickly and we don't have the sufficient skillset for the same and as team has never worked on any OR/M tools it will be steep learning curve for them (This is what i read some where)
I prefer to go ahead with LINQ to SQL (But only fear is microsoft is not going to support or enhance LINQ to SQL further), from my point of view if microsoft is not going to enhance it further i am not having any issue as whatever feature i require in my project it is sufficient.
Now my issue is should i use linq to sql or should i stick to traditional architecture ?
OR else any other option is there ...
EDIT : I am going to use SQL Server as database and it does not require to interact with any other database
One of the most important objective in designing DAL Layer is faster development and maintainability for future database table changes, as there are chances that field may increase or decrease in future.
Also if you feel that any ORM tool is really good and does not have steep learning curve then also we can use
Please provide suggestions
As you are working in medium size project, I would suggest you to use LINQ-TO-SQL because of these advantages
Advantages using LINQ to SQL:
•No magic strings, like you have in SQL queries
•Intellisense
•Compile check when database changes
•Faster development
•Unit of work pattern (context)
•Auto-generated domain objects that are usable small projects
•Lazy loading.
•Learning to write linq queries/lambdas is a must learn for .NET developers.
Regarding performance:
•Most likely the performance is not going to be a problem in most solutions. To pre-optimize is an anti-pattern. If you later see that some areas of the application are to slow, you can analyze these parts, and in some cases even swap some linq queries with stored procedures or ADO.NET.
•In many cases the lazy loading feature can speed up performance, or at least simplify the code a lot.
Regarding debuging:
•In my opinion debuging Linq2Sql is much easier than both stored procedures and ADO.NET. I recommend that you take a look at Linq2Sql Debug Visualizer, which enables you to see the query, and even trigger an execute to see the result when debugging.
•You can also configure the context to write all sql queries to the console window, more information here
Regarding another layer:
•Linq2Sql can be seen as another layer, but it is a purely data access layer. Stored procedures is also another layer of code, and I have seen many cases where part of the business logic has been implemented into stored procedures. This is much worse in my opinion because you are then splitting the business layer into two places, and it will be harder for developers to get a clear view of the business domain.
There is no absolutely preffered way of writing DAL. These are all options. Which one to choose depends on your project, your skills and your inclinations.
Normally, with LINQ you can expect to be more productive. On the other hand, the DAL built with stored procedures can be expected to perform faster.
The issue only comes when you need some specific queries that the default LINQ to SQL provider won't be able to generate to be blazingly fast. In that case you will have to tap into your LINQ code to plug in your custom stored procedures where needed.
Regarding LINQ to SQL support and further development, it was grounded a long time ago already. So no official further development. Note: that is true for LINQ to SQL (it will be taken over by EF) relational solution, not for the main LINQ functionality.
Entity Framework in its v.1 only received massive critics. You're advised to wait until v2 comes out.
The most important limitation with LINQ (over Entity Framework or any other popular ORM) is that it doesn't support 1 to n mappings. That is, each your LINQ class can only map to a single table, not represent some sort of view over several others. Maybe it's not important to you, but maybe it is. Depends on your project.
The argument of stored procedures vs ORM's is long-standing and unlikely to be resolved any time soon. My recommendation would be to go with an ORM (Linq-to-Sql in your case).
Yes, stored procedures will always be faster since the queries are precompiled. The real question you have to ask yourself is whether you have such a performance-intensive system that your users will actually notice the difference. Keep in mind that using stored procedures means that you will need to manually write all your own queries where using an ORM does this for you. This usually means that an ORM will speed up your development.
Since you mention that speeding up development time is one of your goals I would recommend Linq-to-Sql - otherwise you will basically write the entire DAL yourself.
All of the options you've provided have significant drawbacks. None of them meet the requirements you've set out.
You need to prioritize what is most important for you.
If learning curve is your biggest issue, stay away from all ORMs if you are already comfortable with ADO.NET, DataTables, etc.
If development speed is your biggest issue, you should learn an ORM and go that route. The easiest ORM to recommend is NHibernate. Every other ORM has significant weaknesses. NHibernate works in the vast majority of projects, whereas other ORMs are much more situationally appropriate (depending on your DB design, model design, agility requirements, legacy schema support, etc.). All ORMs have learning curves, they just come into play at different times and in different ways.
Just to expand on #Developer Art, using the traditional stored proc approach enables you to put business logic in the database. Usually you will want to avoid this, but sometimes it is necessary to do. Not to mention you could also enforce constraints and permissions at the database level using this approach. It all depends on your requirements.
With the limitations mention I would say just stick to adhoc/custom queries and ADO.NET and not go for any jazzy stuff. Also stored procedure based DAL are faster is a notion based lame arguments like stored procedures are precompiled but they are not. All that they have is query plan cache. So lesser the investment in stored procedures the better you are. My advice ADO.Net and custom dynamic queries constructed from entity objects.
I've been working in ASP.NET for several years now (since the 1.0 days!), but I've never been formally instructed. I'm fully capable of doing pretty much anything I want and I've built several production-level, data-driven sites, including one that does over a million in sales a year (according to the owner). But I'm starting to get the feeling that the holes in my knowlege are dragging my productivity down. I read a lot and try to learn wherever I can to try to stay up with all the new technologies, but sometimes I just don't get it, and I think it's because of my lack of formal training.
Does anyone have any ideas on the best way to fill in these gaps without having to rehash the fundamentals?
Thanks
1) Read the Code of popular Open Source Projects. There are a few that have some really good practices in place.
I recommend checking out BlogEngine.NET. Also if you're more ambitious, I'd suggest looking at the code for ASP.NET MVC 1.0.
2) Sometimes you need to "get back to the basics" when you've been working with a particular framework since a much earlier version. In this case, it can be really useful to pick up a book that covers some of the newer features.
Here's a good book that shows of some of the new features in C# 3.0:
C# 3.0 Design Patterns
3) It may seem odd, but reading up on other languages/platforms (such as Ruby on Rails) will help you in the way you design your classes and code by taking tips of the good and bad of different platforms and combining them.
4) Read some books on general best practices and development methodologies.
Some of these books I recommend are:
The Pragmatic Programmer: From Journeyman to Master
Practices of an Agile Developer: Working in the Real World
Code Complete: A Practical Handbook of Software Construction
I'm in the same boat; been a .Net developer for 6 years. While I do have a CS degree, I don't have any formal training in ASP.Net; I learn it on the job as projects come up.
I found the best way to figure out what to learn is to keep your eye on .Net developer blogs. Some I follow:
David Hayden http://www.davidhayden.com/blog.aspx
CodingHorror.com (you might be familiar with it ;-)
Scott Hanselman http://www.hanselman.com/blog/
Usually from reading their blogs, I pick up on what the latest .Net solutions that are out there and point me in the direction of new tech I should look into further.
Overall though, I can only give you the advice I give junior devs at my company; realize you can't possibly be expected to know everything but always be eager to learn. Good luck!
I can absolutely identify. I've been programming since 1997 and really don't have any formal training to speak of. With regards to ASP.NET, everything I've learned has been through open code (Community Server, BlogEngine.NET, the other ASP.NET Starter Kits), books, LearnVisualStudio.net, and constantly being thrown in the fire.
I have a MASSIVE inferiority complex as I'm always wondering "did I do this the smart way or the inexperienced way". All I know is that my customers are happy, the errors that occur are few and are fixed quickly, and I keep getting work.
Luckily I have a passion for my work and that's what drives me to keep improving (slow though it may be).
If you're a "people person" then I think user group meetings are a great resource. I'm a bit of an introvert and unless someone who's smart reaches across and shakes my hand, I pretty much rely on the speaker's presentation to teach me something new. Probably not the best way to go and also probably why I don't go that much.
But again, I would stress the open projects, especially Community Server.
Seek out people better than you and learn from them.
Take some classes or join a user group.
If you are looking at conferences, consider finding a local Code Camp. These conferences are often very low key, but have excellent information content. They involve local presenters and attendees so you can build up your contacts and a set of people you can run things past when you need help. In addition, you might want to find (or start) a local .NET group where you can learn together. These can be hard to get off the ground, but when done well can be an excellent source of community learning.
Look for interesting ways to break your established patters - even at a loss of productivity.
Otherwise, it sounds like you are already in a pretty good spot. You can deliver on current requirements and sound like you can pick up new tricks when needed.
Really, the best way to learn new techniques is to work on a different project - even if that means changing jobs. If you have relevant and continuous experience since 2001, you should be able to pick your projects.
I've been coding PHP on a current project and it's been an interesting break from webforms. If anything, I'm getting good perspective on both models and really looking forward to doing some work in MVC.
I'll probably get some -1's for this, but as a fellow ASP.NET developer I don't think you really need to learn ALL that the framework has to offer. The reason I say that is that over the years my LACK of knowledge of all the cute little conveniences of ASP.NET has caused me to write better performing and more robust web apps for Windows. Balanced design patterns (separation of concerns) WITHOUT OVERDOING IT will make more of a "better" ASP.NET web app than using all of the controls and tools that come with the framework.
Case in point is the ajax stuff you get with ASP.NET, and also data binding. Since ASP.NET was late in the game with Ajax, I started off with my own ajax wrapper (based on an early ajax book) and then moving to jQuery. My co-workers all swear by the UpdatePanels and 3rd party controls, and quite often the user experience ends up worse and more confusing than a regular post back (and then we have to inject javascript to make it perform better and more seemlessly). As far as data binding, I've yet to find a canned control (from Microsoft or any 3rd party) that handles 2-way binding better than the framework Rick Strahl came up with back in the 1.1 days. We built a framework on top of a paper and some base classes he released, and I've yet to see something that I think handles data binding any better in ASP.NET (well...besides WPF/Silverlight...those frameworks really nailed it IMO).
So, to me, the path to upgrading your ASP.NET skills is to come up with some good ways to separate your business logic into logical components in the cleanest possible way, and learn the hell out of C# and JavaScript (and/or a JS wrapper library like jQuery). For me, coming from a LAMP background before learning ASP.NET, I absolutely love C# and Visual Studio, but I'm not such a huge fan of the high level ASP.NET controls.
This is a pretty broad question, and hard to address. I perceive myself in a similar space to you, so I guess I can elaborate on what I've been focusing on to improve as a developer which might be of some help.
I mostly write business and commerce related web apps, and my focus has been on a developing a solid understanding of separation of concerns, domain driven design, and enterprise design patterns.
Some books on general software design which I found revelatory were Code Complete by Steve McConnell and Head First Design Patterns by Freeman & Freeman.
I read SO, Code Better, DDD Step by Step, and a number of other blogs regularly.
Dissect well written code from others, and learn from them. Learn from your peers. If you're in a stifling work environment that doesn't give you the opportunity to grow as a developer, consider looking for a new job.
Learn a new language in a completely different framework - I've been teaching myself Ruby on Rails at home and it has given me an interesting perspective on the ASP.NET work that I do commercially.
Given that you're an ASP.NET web developer, learning MVC.NET will certainly help you to think about front-end development in a new, refreshing way.
If you can afford the money and time (or can get your company to pay for it), take a course at DevelopMentor. They have courses across the country and all year round. They are generally a week long and are in depth.
As someone who has spent around 10 years programming web applications with Adobe's ColdFusion, I have decided to add ASP.NET as a string to my bow.
For someone who has spent so long with CF and the underlying Java, ASP.NET seems a little alien to me. How should I go about getting up to speed with ASP.NET so that I can be truly dangerous with it? Do I need to know C# at any great amount of detail?
I want to be in a position where I can build basic web apps fairly quickly so I can learn more doing the tricky stuff.
I'm only maybe six months down the same path, but here are some thoughts from my experience so far:
The C# language shouldn't give you much problem if you have very much experience with Java at all (or even CFScript). As a reference, though, when I was starting, I found csharp-station a good primer for language basics. It won't help you much as far as the ASP.NET side goes; but it is good for syntax. More you'll be familiarizing yourself with the .NET libraries. The IDE actually can be an enormous help here.
Here are the three biggest differences I found making the transition:
ASP.NET Server Controls - In ColdFusion, you really have pretty
direct control over the HTML; you
work very closely with the page.
This isn't so much the case in
ASP.NET. The server controls are
meant to relieve you of a lot of the
tedium, but at a cost of maybe some
direct control. As a CF programmer,
I'm very particular about what gets
actually output to the browser; and
at first ASP.NET frustrated me
because it spits out a lot of extra
code. Still, the controls are
really powerful, and it pays to
familiarize yourself with them.
Form and validation controls,
especially, save you from a lot of
the tedium in CF of handling post
back and validation. W3Schools
actually has a decent list of web
server controls.
The page model - ColdFusion is pretty agnostic in terms of page
flow. ASP.NET is very much geared
towards using post backs, and is
very event driven. If you're not
using a framework with CF (e.g.
Model Glue), this may be foreign to
you. .NET takes care of handling a
lot of the post back behavior for
you. Also, not to say that
ColdFusion can't be object and
function driven by good use of
CFC's, but ASP.NET really tries to
push you down the OO path compared
to CF in my experience.
Database access - Using ASP.NET really made me appreciate how
powerful cfquery really is. The
csharp-station site also has a good
tutorial on working with the native
.NET db tools. I haven't worked on
enough projects yet to start looking
around for DB access extensions; I'm
pretty sure Jeff recommended
something that they used for
building this site, so you might
check that out. Otherwise, I really
suggest you familiarize yourself
with the DataSet object. It's
somewhat similar to a query object
in CF, and lets you run query of
queries, etc... Looping over
queries in CF is very common, but it
doesn't happen nearly as much in
ASP.NET because of data binding.
Microsoft has a video called ASP.NET for ColdFusion developers you may be interested in.
Edit, here's another
ADO.NET is a core concept, and I would really recommend taking a course in it. Having a qualified instructor explain exactly what the differences are between a DataSet, DataReader (and so forth -- there are a lot of different data access object types) is invaluable. Not to mention you'll better understand the appropriate time and place to use each; and you can ask questions and get immediate answers in a classroom setting.
I took an ADO.NET class (one night a week, about 8 weeks) at my local university for around $400. Even if my company hadn't paid for it, I would have been happy to, and I can highly recommend anyone trying to learn .NET do the same.