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 9 years ago.
Improve this question
I am in the process of architecting an application. It will be a large, enterprise class web application. Thousands of users could upload files, search large number of blog entries with chat functionality and such. It will also have mobile interface. It should be highly testable, scalable and flexible.
I have narrowed it down to three environments: pure play ASP.NET, pure play DotNetNuke (DNN) and a combination of ASP.NET and DNN. To keep this very brief, here are some 'for' and 'against' on each of the options:
ASP.NET:
for: highly scalable, supports patterns like MVC, testable, consistent architecture.
against: long development time.
DotNetNuke:
for: short development time, large number of existing functional modules and skins.
against: architecture is sealed, can't support MVC, unit testing is difficult, inconsistent modules/skins, potential upgrade issues, user experience is inconsistent due to disparate modules from different vendors, poor documentation.
So, the questions are: what do you think? Has anyone switched from DNN to ASP.NET (and, vice versa)? Have you objectively evaluated these two and what did you choose?
Highly appreciate your help. Thanks.
henry.
DNN is ASP.NET, just with a lot of the work done for you.
Also, please remember that just because raw ASP.NET has the potential to be more scalable, doesn't mean that you are actually going to built it to be more scalable. Or that you will built it well in the first place.
It comes down to a trade off between control and resouces/talent. If you have many very talented developers (like, top-10% talent), a lot of time, clearly defined requirements for your site, and consumers who will be patient while you build out the infrastruture, by all means go with raw ASP.NET.
However, if you need to build it quickly and need to be flexible, or you have limited development resources, you might have to sacrifice some of that control and unit testing and potential performance (again, the "potential" part is key here).
Based on what you are looking for, I'd recommend you go with a platform like DNN, or a million other ones line SiteFinity or Umbraco or Orchard or something like that (some of them like Umbraco give you MVC too). It gives you a lot of the infrastructure and plumbing common among a lot of sites, probably done better than you are going to do it, so that you can focus your resources on the truly unique aspects of your application.
Just stay away from SharePoint. It's evil.
I've built raw ASP.NET sites for really customized applications, which was good because I didn't need a lot of plumbing and wanted really unique funcitonality through the site. But then I've built social networking sites with DNN, which worked well because it had packaged components for blogs and forums and chat and all that stuff, plus allowed for easy skinning. I designed another application for a customer that they wanted to have a lot of custom functionality, but they also wanted to updated a lot of content and internatalized it, so we used a Umbraco for that. And right now I have a ASP.NET app that works great, but I want to add in some social features, so I'm going plug in a Umbraco or DNN site that integrates with it to host the more common social components.
I would definitely recommend DNN based on your very limited list of needed features. You can always build a custom module to meet your exact needs or modify an existing open source module as needed. You can use the MVP approach in your module development to improve the testability.
Have you considered the Umbraco CMS? It is built on .Net (v5 is MVC3). It is open source and a very robust and well supported application. It has been used for the asp.net site for example.
It has a very short development time, many modules, extremely flexible and I find it very easy to extend. For example, I rolled my own workflow, event driven publishing and have created multiple custom administration sections for managing bespoke functionality external to Umbraco.
You can use XSLT, Usercontrols or Razor to create template modules.
It has a fantastic community too.
Related
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 7 years ago.
Improve this question
I have an web site built in ASP.NET. It is a business website that works with a lot of data.
I had a lot of problems, especially of speed and effectiveness, so I did what I can with ajax, and speed greatly improved.
I wonder if I should switch the web site to ASP.NET MVC?
I don't know ASP.NET MVC very deeply, so I want to know if I should invest in it, the main question is: Is ASP.NET MVC faster and more effective than regular ASP.NET?
I believe that ASP.NET MVC is (if not, already has) becoming the mainstream way to develop websites in using the ASP.NET stack. There is a lot less emphasis on ASP.NET WebForms in the last few years, which hints that MVC is the sensible choice for starting new projects (Note: WebForms is still a popular choice for some devs though, I'm not saying don't use it ever. There's still a place for it.)
Regards migrating existing ASP.NET WebForms apps, I would be a little cautious. Don't switch to another technology unless you have a very, very good reason for doing so. Depending of factors such as the amount of code, the design, it could take a lot of effort to convert an ASP.NET WebForms project to ASP.NET MVC.
In your situation you mention performance issues, which made you consider moving to ASP.NET MVC. I would look more into why your site is not performing as you would like. Use a profiler to measure which code paths are taking the longest ot execute. There are plenty of sites built using ASP.NET WebForms which perform to high-scale, so I would not make the mistake of moving to another technology in order to solve a performance problem.
It depends on where your current issues are.
Should you learn MVC - definitely.
Should you write new applications in MVC - sure.
Should you migrate old applications - depends.
What's the architecture of the current application?
How much time/resources do you have to allocate to a rewrite vs fire-fighting the existing app?
Is there a clear data or middle tier or is the data access built into each page code behind? Many applications are written so that the front-end can be swapped easily or called from other applications (eg via an API) but many webforms applications (not all) are written without these considerations and so it wouldn't be a swap out but a complete rewrite of the application.
What are the current issues other than "it's a bit slow"? For example I've seen an app that loaded the entire data model into memory for each page - simply changing the front-end would make no difference in this case as the cause of slowness was the data loading. Changing the architecture to load only what was needed significantly increased the speed.
The improvements you can get from using MVC aren't necessarily the business level ones you might expect. There are plenty of sites that go into this in more details, here's some to get you going:
MVC generates (much) cleaner HTML in the output - so pages are easier to develop/maintain and easier for developing UI interactions in javascript.
MVC has a much improved pipeline which can be hooked into, eg for adding action filters.
IoC/DI is hugely easier in MVC
Separates the model/controller code from the view html
Your application users won't care about any of these.
I have the same situation with one of my clients and after learning the MEAN stack and working with another company who made the transition to Nancy. I would recommend doing a REST API with Nancy and a pure front end with Angular or another Javascript front end. This will allow much faster response and flexibility down the road. Plus it will give you more flexibilty if you ever want to expose your API to other apps.
I tried to move from Web Forms to MVC and it was not very easy for me at the time.
You can use Asp.net Web Forms, with more ajax and less post backs and less view state usage if you do not want to move to asp.net mvc.
Asp.net MVC on other hand is very good with light wight pages and capabilities to blend in with client side ajax based solutions. And its architecture supports scale ability.
I think you should definitely take the time to learn MVC, as it is becoming a more marketable skill and future projects are more likely to call for it.
With respect to being faster and more effective, it is somewhat. First off, WebForms have a lot of overhead in order to have this windows-forms-like behavior (which, frankly, has never been a perfect fit for web pages). Second, MVC tends to render HTML that is much cleaner without the view state or long IDs. So those two items can make it faster. (Of course, if you are having speed issues you also need to look hard at your host server.)
With respect to rewriting your current project to use MVC, that's a more difficult question that only you can answer. WebForms still work and will probably be supported by Visual Studio for many years to come. Depending on your project, rewriting it can be a costly task. So you'll need to decide if it's worth it. That said, I hope to rewrite all my webforms websites using MVC as time allows, although part of the reason is just to update the look and make them more responsive to mobile devices.
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 6 years ago.
Improve this question
I know this has been asked a lot and I've explored the other answers, but I still have questions, so hopefully this sheds fresh insight on the debate.
A year ago I built a service scheduling web app from scratch in CodeIngniter with the following functionalities:
user management with different roles and functionalities
different backends for each user
interactive and manageable calendar for scheduling services
territory management and assignment
management for service status
reports and records
billing with authorize.net
front-end informational pages
All pretty standard stuff and codeIgniter worked great. Now, a year later, I'm revising the code. The client wants some different management features, like a CMS for the pages and to add new services and change the calculation price points, etc. I need to add new classes and code to make this work.
Over the last year I have dove very deep into Wordpress and realize that I could have built this whole app in wordpress using custom post types, taxonomies, custom fields, and expanded custom functionality though a custom plugin. In many ways, this seems like it would be better.
Pros of using Wordpress instead of php framework:
existing base with CMS, user management, familiar backend, database structure to start from, saving lots of development time
constantly updated security
stability
robustness (I know wordpress can handle this even though its intended use is for blogs)
Reasons to use a framework:
flexibility
ORM
MVC
other?
So... which is better? Do I really need ORM or MVC for this project? I feel my development efforts and client ux would be easier if I use Wordpress.
What else do I lose if I switch to wordpress?
What about combining Wordpress in a framework, or vice versa? Recommendations?
When does it make sense to use a framework instead of wordpress?
It's a fairly broad question, so here's a fairly broad answer...
Wordpress is a CMS. It's a good, flexible CMS with lots of built-in goodness, but its sweet spot is managing a site that's primarily about content, where content is very broadly defined as "words, pictures and other assets". The plug-in model lets you build/use additional functionality, and the wide user community provides lots of stability/security/scalability help.
Code Igniter is a framework that's designed for functional web apps (in practice, this usually means database-driven apps). Its sweet spot is managing complex interactions with a business domain. It is a framework for building any kind of app (including, if you were glutton for punishment, a CMS).
If your business domain is about content (and I don't think it is, based on your description), Wordpress is an obvious winner. In your case, I think you could probably build the solution using Wordpress, but it would be a real edge case - and the benefits you mention of "security, stability, robustness" would likely not apply, because you would need to build a lot of custom code. I think you'd very quickly get to the "well, it's not the way Wordpress wants me to work, but to deliver this feature, I just have to do it this way" point.
When business users say they want a CMS, they usually don't mean they want Wordpress (or Drupal, or Sitecore, or Magnolia); they want to be able to manage their site without having to go to the techies. If your site is primarily database-driven, that means screens to manage database records.
It's about structure and function in my view. Both CMS(Wordpress) and PHP Framework provide structure/functions to build your own functions. You can do the same things on CMS and Framework. They shouldn't have much difference on performance and security amongst well known Frameworks and CMSs.
However, CMS focus on Front-end (contents?), provides with ready to use CSS, Javascript (Front-end) in order to build / manage websites and web based applications easy and quick. Though, it's not very clear in structure comparing to MVC model.
Both would do the same job if you develop yourself, but in a team, framework could provide benefit.
It's only my view, I am using Wordpress a lot and a little knowledge on framework.
I use CodeIgniter and my bias is for that because you've already built the bulk of your app in it and because it seems more flexible/less pre-configured than Wordpress. I also get the feeling that CI is growing in use relative to WP with developers so CI seems possibly more future-proof, though to be fair they are both popular.
Can you make clearer you're bosses demands? The way I read what you say is that you're 80% of the way there and then are considering scraping (or at least possibly having to heavily revise) that 80% because the other 20% seem more logically done in Wordpress.
As I learn PHP more, I'm actually finding myself using even less of CI and writing more straight up PHP or actually JavaScript (for even better UX). So I guess I'm surprised to hear of someone wanting to switch from a minimal PHP/ruby/Python framework to a heavier one since most of the work is shifting to JavaScript these days.
Another key point on going towards straight-up PHP is that the number of people who know PHP dwarfs the number of people who are familiar with CI- or WP-specific syntax. So you are more likely to get help/collaborations/career advancement focusing on a solid foundation in the "mother tongue" over these minority dialects. Doing this with PHP is also having the benefit of helping me understand other languages such as JavaScript better since the level of abstraction is on the same page with php-ruby-python, whereas a framework brings in an entirely different (an in my increasing view, extraneous) vocabulary.
I've started to wondering whether ASP.NET Webforms/MVC even have a place in the web developers toolbox anymore... It seems that CMS systems like Umbraco have replaced the web developers job. Yes I know that those CMS systems are built with ASP.NET Webforms/MVC - however is there even any reason for learning those things if all you gonna do is to use a CMS system anyway? - Also I cant find any situation where a CMS system can be replaced by your own web application.
My question is therefore: Is there any reason for learning Webforms/MVC when using a CMS?
EDIT:
My question might be more like: When should I use a CMS, and when should I go and build my own web app?
The problem with CMS solutions, and I mean all CMS solutions (not just Umbraco, or other .NET solutions, but in any language) is that you will always pay a price for using them. You may gain more from the time-savings afforded by using the CMS, but there are trade-offs to consider:
You will sacrifice a great deal of flexibility
You could pay a significant performance penalty. Many CMSs load a large amount of modules and code to service every request, and much of this is not relevant to a particular page function. (though some CMSs are more monstrously heavy than others!)
The future of your project is tied to yet another vendor, and their own choices
Very often, you rule out the possibility of using other databases that might have better fit your customer's needs (Umbraco doesn't support PostgreSQL, Kentico only supports SQL Server)
Once you start using a CMS you will be tied into satisfying the architectural decisions and API of the CMS framework, and you could eventually be backed into a corner.
This can be particularly problematic if your 'site' is more of a web application than a pure content delivery site. In such cases it can make more sense to choose to build using the full flexibility of the web application framework, rather than risk getting backed into an architectural corner.
On the other hand, if you are building a web site that has potentially hundreds of pages, with a lot of user-contributed content and is much less of a web application, then often a CMS is the way to go, and makes a lot of sense. But remember, you now have two frameworks and two APIs to learn and manage (your platform's framework and the CMS framework).
Writing a CMS is like invading Afghanistan.
Everybody gets a turn but nobody wins.
I don't think that Stack Overflow could have been built with a CMS. Does that answer your question? =)
Update
To answer your updated question.
If you want a regular corporation web containing news, articles, forum etc: Go ahead and use a CMS.
If you need to build a more custom web site like stackoverflow, a web interface for a system or anything like that: Built it using MVC etc.
I personally use a CMS for our corparate website and a MVC framework to build user and administration interfaces for our products.
Not every problem needs a CMS. In the same way not every problem needs a bespoke MVC/webforms website. It depends on what your requirements are. You pick the technology to solve the problem.
Build vs buy is the hardest decision to make. As a developer build always looks best. You can do better than that pile of carp they want to buy. Nevermind that you're reinventing the wheel, axel, cart, etc. To users/management buy always looks best. They don't have to think to hard about what they want and can have it now, not 3 months later after you write it. They forget it'll cost the same again to customise & make it impossible to upgrade.
I'll stop ranting now.
Umbraco is a pretty bare minimum CMS. To customize it (e.g. Version 7+) you'll need to know Heavy MVC, JSON, XML, Sql, etc.
In fact a Site built on Umbraco 7+ is entirely based on MVC views you set yourself and assign to SurfaceControllers (which are MVC controllers) and all you are really getting is the ability for users to edit things about your pages and have Umbraco manage it for you in a DB.
In short you still need experienced web developers to build a site on Umbraco, they just save a lot of time by not having to build the entire backend from scratch.
You use Umbraco to organize Document Types that define what Templates (MVC Views) are used for rendering different types of documetns (e.g. Web Pages) and then you built the template from the ground up with 100% control over the HTML, Css, and Javascript that get's output.
Imo Umbraco is more of a Framework like Django than a complete CMS.
Sure you can build a site in Umbraco and not customize anything, but it would be a pretty cheesey site.
The whole point to Umbraco is to give skilled .Net Developers a good platform for building a site on top of it, but they still have to build it.
Now sharepoint would be more of a complete CMS out of the box that you can do a lot with, but let's see a few problems with SharePoint...
Resource Heavy, eats 50+ Gig's to install
Eats 16 GB of ram just to boot it up (Sharepoint 2013)
Requires Sql Server 2008 R2 or equivalent (enterprise license, $$ chaching)
Requires Windows Server ($$chaching)
It's a monster basically, if all you need is a user editable blod platform... man what a waste of money. Foundation is free, but doesn't include things like the Blog Site Template, so you buy a server enterprise license ($$ big cachinge, 40,000$+ in some scenarios...)
Agreed. A CMS like Umbraco provides a (very) good out-of-the-box solution for the most basic applications. Any sort of specialized purpose is going to require additional programming knowledge. Anymore, though, and your major, if not primary need is going to be a good understanding of the business need. I think we're getting away from building the Legos themselves and on to building the neat toys with the Legos. Cheers!
A CMS (or similar application framework) will provide you with a lot of functionality out of the box, and many of them also have a good library of plug-ins. But you'll still need to write WebForms/MVC code if you want to add any custom features.
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 8 years ago.
Improve this question
Our team is divided on this and I wanted to get some third-party opinions.
We are building an application and cannot decide if we want to use .Net WPF Desktop Application with a WCF server, or ASP.Net web app using jQuery. I thought I'd ask the question here, with some specs, and see what the pros/cons of using either side would be. I have my own favorite and feel I am biased.
Ideally we want to build the initial release of the software as fast as we can, then slow down and take time to build in the additional features/components we want later on. Above all we want the software to be fast. Users go through records all day long and delays in loading records or refreshing screens kills their productivity.
Application Details:
I'm estimating around 100 different screens for initial version, with plans for a lot of additional screens being added on later after the initial release.
We are looking to use two-way communication for reminder and event systems
Currently has to support around 100 users, although we've been told to allow for growth up to 500 users
We have multiple locations
Items to consider (maybe not initially in some cases but in future releases):
Room for additional components to be added after initial release (there are a lot of of these... perhaps work here than the initial application)
Keyboard navigation
Performance is a must
Production Speed to initial version
Low maintenance overhead
Future support
Softphone/Scanner integration
Our Developers:
We have 1 programmer who has been learning WPF the past few months and was the one who suggested we use WPF for this.
We have a 2nd programmer who is familiar with ASP.Net and who may help with the project in the future, although he will not be working on it much up until the initial release since his time is spent maintaining our current software.
There is me, who has worked with both and am comfortable in either
We have an outside company doing the project management, and they are an ASP.Net company.
We plan on hiring 1-2 others, however we need to know what direction we are going in first
Environment:
General users are on Windows 2003 server with Terminal Services. They connect using WYSE thin-clients over an RDP connection. Admin staff has their own PCs with XP or higher. Users are allowed to specify their own resolution although they are limited to using IE as the web browser.
Other locations connects to our network over a MPLS connection
Based on that, what would you choose and why?
I am especially interested in hearing from developers who have experience with both ASP.Net and WPf.
Reasons to choose WPF:
Much faster and easier development than ASP.NET and jQuery
Much easier to implement quick incremental background loading of data
Much easier to implement client-side caching of commonly used data (important for remote offices)
More efficient data transfer from server (can use advanced WCF features unavailable to web browser)
Keyboard navigation better, since you can easily define shortcuts, etc, and not be limited by browser
Maintenance overhead much better using MVVM pattern
Softphone integration easy
Reasons to choose ASP.NET and jQuery:
None that I can see
In your scenario I would definitely choose WPF.
First of all, I would sit down and write the business requirements and specifications. It really doesn't matter what tech you use - proper planning will affect your project timeline more than technology choice. This is especially true for an in-house custom built app.
As far as development, I would take the requirements and lay out the backend functionality. I would actually implement the backend in WCF, regardless of the client technology - that way you could use best of both worlds if needed (for example for phone integration you could write a stand-alone WPF app). ASP.NET with jQuery can easily use WCF services (JSON or XML version) together with desktop client.
As far as development of the client forms, this highly depends on developers experience and your future plans. I am not going to go into advantages/disadvantages of developing web software here - there are a ton of articles in the last 10 years about cloud/web based software (for example salesforce). I would rather concentrate on deliverables - what is your team most comfortable with today and in the future. There's a huge difference between WPF and web development, from development standpoint, and it requires completely different experience.
Why not consider a hybrid solution - Silverlight
With Silverlight you get most of the goodness and statefullness of WPF (with almost exactly the same XAML and code), plus you get the deployment characteristics of ASP.NET
Many people consider Silverlight the next step after ASP.NET/AJAX, and it would definitely deliver all of the benefits of WPF relevant to your scenario.
WPF is the way to go, without a doubt. I agree with all that #Ray Burns has said.
Because:
You will get a richer, slicker, faster application.
It will be easier to build1.
Softphone/Scanner (i.e. hardware) integration is going to require browser plugins etc. and this can be a nightmare with a browser based application.
Keyboard navigation is still better with native applications.
IME Maintenance is easier with WPF applications.
Definitely use WCF to provide the backend via The Entity Framework, see The Entity Framework In Layered Architectures. You can do have a better integration with the backend in a native application because it can be called inline - no need for callbacks or ajax. I've built components for WPF that are linked via EF to the business logic to provide aware controls for simple stuff like validation. It's stunningly good to drop a customer name field onto a form and it just works.
To add additional components you need to build it with a proper well thought out plugin architecture. This is the same in both environments. I've got some thoughts on this I jotted down in my journal entitled Designing a plugin architecture for an application
When building a WPF application you will be writing in one language (e.g. C#) + markup (XAML). When building asp.net you endup with two languages + markup, as you always have to code some Javascript.
So, based on your requirements it has be to WPF / WCF (EF). A web based application will be a lot more work, more complexity, and not be as nice.
About 12 months ago I was fortunate enough to be given a free hand to choose the technology for a new application. I spent almost a month evaluating all of the options and came to the conclusion that it had to be C#, WPF, Entity Framework. After writing the application I can confirm that it was the right choice...
1. It will still be easier even if your programmers have to learn WPF first. WPF is much better thought out, great and lovely. very lovely. It just works right.
Hi
I think The question at issue is Windows-application or Web application(WPF for win-app VS asp for web-app), Which one is better for you and your project?. In this case your platform is network and your program must work on the net. so for this usage Web-app is better but there are a lot points existing which can make decisions hard. Network platform has great challenge.(according to my personal experience)
Working with web-app by asp.net is nearly hard. you must try to handle many thing's for web-app(request time, session management, even poor UI in comparison to WPF, j-query, etc ). Remember this is not as easy as simple web site.
But win-app is good for network with this condition: "local network"(mpls is almost the same). Absolutely developing win-app is easier than web-app ("At least number of users expert in net-program developing"). for this case WPF has many good things(UI , command, etc) also has many challenging point(like multi-threading and lack of expert developer in this field ) . I'm rather with wpf than asp but decisions is yours
And chalk point to good thing Silverlight but if you want to use this you must look at prism framework : http://compositewpf.codeplex.com/
I have recently developed a project separately with asp and silverlight(prism framework). developing silver-light version is too hard and takes more time than asp.net version but at the end SL-ver have great look nothing else!
Burns pointed to good issues about wpf. also consider Artemiy's post. your environment conditions is same for both of them. WPF/ASP can work with scanner and soft-phone cuz the base of both is on C# and .net library
Finally what ever your decisions is you must hire advance developer at least develop one business-app for the network platform.
Is your app a desktop app or web app.
If Desktop wpf is best.
If web based asp.net is best.
Don't front load your development with your get it up quick scenario. That never works well and results in a sloppy deployment. Take your time, cover all the steps (Business Requirements, System Design, Program Design, Code, TEST and TEST some more, Deployment)
Some points to be made for ASP.NET:
The pool of ASP.NET developers is much larger then the pool of WPF developers.
Which means you can probably find qualified ASP.NET developers easier.
ASP.NET is probably more future proof, chances of WPF getting large changes and being hard to port to later versions is probably larger.
Also keep in mind that the focus of MS seems to be on Silverlight so there might be a consolidation down the road which makes WPF obsolete.
More mature eco system of ASP.NET makes for more out of the box solutions to use to solve problems.
With multiple locations you might be able to skip a few layers and go directly to a website?
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 2 years ago.
Improve this question
How much of ASP.NET or C# is required for Sharepoint development? Do you need experience with things like developing N layered web applications, design patterns, test driven development, strong SQL background etc?
I hear that Sharepoint development is different from enterprise applications thats typically built with technologies like ASP.NET.
If I know my basics in .NET, C# and have some experience with ASP.NET and have good understanding of things like Page lifecycle in webforms, web parts, Master pages etc, then am I ready for Sharepoint?
Also, is Infopath very heavily used in Sharepoint development?
If you already know ASP.NET than you are ready for SharePoint development. Get familiar with its SDK and other development concepts. SharePoint Dev Wiki might also be a good start.
A must have for new developers is to learn SharePoint from end user perspective. I am using this book to train the new guys. If you do not understand these concepts it might be hard to start coding.
It really depends on what you are wanting to achive, there are more than a few ways to develop something for SharePoint each requires different skills.
for example :
SharePoint exposes a number of webservices which you can use to complete a number of tasks.
A step up from that Sharepoint has a number of DLL's you can reference directly in order to access a more granular level of detail, but is more fiddly to work with.
Neither of these require any knowledge of ASP.NET but both work with sharepoint.
If you are planning on making a WebPart then yes ASP.NET knowlege is a big plus.
If you want to work with the Sharepoint workflows then you need knowlege of WF.
There is no one fit for developing sharepoint, which quite frankly makes it hard to hire people for it.
I guess it really depends on what you mean by SharePoint development. In my humble opinion you must learn what SharePoint provides out of the box in order not to reinvent the wheel all over again.
The object model, web services and how to deploy your work using solutions is something you have to pick up very quickly in order to be a good SharePoint developer.
As I am more of a consultant type when a developer I can't say whether you should know SQL and AD but I guess it won't hurt a bit.
If you are fluent in C# it might also be a good idea to have a closer look at PowerShell as it sure looks like Microsoft will integrate PowerShell in all server products including SharePoint 2010.
I don't think it's much different, really. I've been learning both at the same time to some success. Of course, ASP.NET and SharePoint are just different things, but SharePoint is built on ASP.NET, so to the extent you understand ASP.NET, you also understand SharePoint.