We are working on a unique eCommerce site. This site is distinctive because when a purchase is made its not made by one person, but a group or "Collaborative" decisions. Individuals can add items to the shopping cart, but in the end the purchase is decided by the group in a “Collaborative” effort or Team Effort. So each team member is given tasks, inter-team messaging, can rate functionality with surveys, set milestones, rank specific features that are important to them. Another big part is that many aspects of the site allow for comments from members of the group. So many of the items in the application are “comment able” by the team. Is there anything we can buy (C#/ASP.NET/MVC) that gives us this functionality. Comment, Task, Survey, Rating, Messaging, Ranking Collaboration engine?
A lot of the features you mention are available in Microsoft's SharePoint 2010 platform - this software is intended exactly for the type of collaborative scenarios you describe including surveys, tagging, workflow, alerts, etc.
There are two versions of the product: SharePoint Foundation and SharePoint Server. The Foundation product is free and contains many of the basic collaboration and workflow features. The Server product contains much more - too much to list here - but is not free.
The 2010 product is built on ASP.Net 3.5. You can build both public-facing and intranet sites using SharePoint as the underlying platform. Also, SharePoint has many extensibility options, so if the off-the-shelf product does not contain a feature that maps to your particular requirements, you may be able to write custom code to extend it.
As a starting point, I would suggest you check out the features on the Microsoft SharePoint product page.
Related
All,
I am building a typical database driven helpdesk application.
I would like to enable the users to create workflows that will do the following types of tasks:
Add a new ticket (a set of records in the database) at a given time
of day, or date of the year, or a future date of some kind.
If the ticket has a specific type of metadata such as a category and priority combination, it should set up an office outlook task and email it to someone.
When the task gets updated, the task will update the next step in
this workflow based on the response of the task.
Etc…
I would use WFF, however in my case, I need to build the application that the end users will build the rules/workflows for, and the end users are average computer users.
Please give me some pointers, and some direction.
Bill
I think Nintex are trying to hit your problem on the head with thier Workflow2010 product.
You're able to host the Windows Workflow Foundation Designer within your application and give your users a custom set of activities.
By providing a custom set of activities you could ensure that users are able to use the designer with only a few workflow knowledge.
Another solution may be SharePoint. Microsoft SharePoint Foundation is shipped with every Windows Server 2008 R2. Older versions of Windows Server are shipping Windows SharePoint Services (Which is the free version of SharePoint 2007).
SharePoint is great in managing lists and listitems. SharePoint is built to make collaboration easier by using a great platform. The SharePoint platform itself allows you to run custom workflows based on items within lists.
So I think you should review your technical decision. And investigate a little more time in reviewing existing solutions that are achieving your requirements.
Thorsten
Consider having a look at Workflow Engine. It's a .NET component that enables you to update workflow steps with external commands/events, has timers, and, more importantly for you, a visual designer.
I have less information about share point (only basic info). Microsoft released SharePoint for web developers. Microsoft also said SharePoint has compatibility with other .NET technologies like Workflow Foundation, WCF, etc and it's easy way to develop web sites and web apps.
Also as I know ASP.NET has compatibility with .NET technologies and C#. And it easy for every one whom at least work with C# or VB.NET.
So with these advantages of SharePoint:
Why we must use asp.net instead SharePoint?
Why Microsoft develops ASP.NET (new version 4)?
What's major reason to chose one of these?
Is really developing base-on share-point faster and easier than asp.net?
SharePoint is an Application that sits on top of ASP.net (3.5 SP1 in the current SharePoint 2010 - No ASP.net 4.0 will be possible). They do override a lot of ASP.net built-in functionality (they have their own .aspx Parser and Virtual Path Provider for example).
With ASP.net you have a very well documented, battle-hardened, mature and stable platform with a good API.
With SharePoint you gain a poorly documented, bug-ridden, very limited application that handles a lot of features that you would have to code yourself (e.g., User Profile Management, Document Organization and Versioning and Social Features like Commenting and Tagging), although for the most point SharePoint handles them really poorly and does not allow you to override them, which means that you spend a lot of time rewriting them anyway and trying to integrate them back.
Basically my advice as a SharePoint developer since 2006: Use it when you absolutely have to, avoid it whenever you can and stay with just ASP.net.
SharePoint is good as a simple document management and very light social system. You can quickly customize smaller parts of it and add a lot of value to your company. But in the moment you need something that even only slightly different from what Microsoft envisions, you hit a wall that you can't pass. It's great for what it does, nothing more, nothing less.
I am a Sharepoint Developer... And let me say that I wish it was just ASP.NET! That would be great... It brings with it it's own paradigms which are pretty complicated.
ASP.NET and Sharepoint are 2 'different' technologies. Sharepoint is mostly built with ASP.NET, and delivers ASP.NET pages to a user.
You can use either VB.NET or C# with Sharepoint.
In my opinion, Sharepoint development is only quicker if you are planning on using it's in-built lists, user management etc. Though these do take time to learn. The cool thing about sharepoint is that you can develop web parts, and re-use these web parts on multiple pages throughout the installation.
Microsoft continues to develop both ASP.NET and sharepoint because they are two different beasts, with ASP.NET pages being deliverable through Sharepoint.
As to which is best for you, you haee to make that call. Do you need Sharepoint? Or would a pre-built CMS such as DotNetNuke be better? Or even creating your own site with Windows credentials management so you can use SSO (Single Sign On).
It really depends on what you want to get out of your install. Sharepoint is expensive, and developers for Sharepoint are also expensive because of the specialist knowledge.
As a developer... (I hope my boss isn't watching!!) I much prefer to build things from scratch than to use SP, but that's my job...
Don't use sharepoint unless you need it, check this article:
Challenges when using SharePoint compared to ASP.NET
If you just want to create a website, go for ASP.net.
However, if your company has a SharePoint installation and you want to integrate with that, you should go for SharePoint.
SharePoint is build on ASP.net, but has many extensions that allow data to be shared throughout the company.
However, if you are just building a website and don't need all that, ASP.net is the way to go.
I'll try to answer point by point:
SharePoint isn't a replacement for ASP.NET. It's an extension of the ASP.NET platform that simplifies the implementation of several common use cases that are mostly relevant to enterprise websites: document management, knowledge retention, collaboration etc... SharePoint relates to ASP.NET in a similar way that Wordpress relates to PHP: it's a specialized extension rather than an alternative.
Same explanation as in (1).
Use SP if the things you need to develop are in the scope of what SP provides, which is mostly enterprise solutions of one sort or another. Here's a good summary of what SP can do.
Again, it would be faster and easier if you're trying to develop the things that SharePoint is meant for. Also, SP isn't so well-documented, so if you're not familiar with it, you might have a slow start.
SP is a very powerful platform, however, it does seem to bring complexities to the table that otherwise may not be there with simple ASP.net. Plus when you move "OOTB" with SP it becomes a bit challenging with RTM, etc. I live in blogs with "weird" things that happen. I am not a full blown SP developer but have been working with it for over 7 years and well, I find building solutions that will work within SP, but not necessarily built withIN SP generally are going to be easier to maintain and controllable. Just my opinion!
I would compare all for you and its up to you to decide.
ASP.NET >> Its a programming language by Microsoft which means you would need Windows Server + IIS + Database server like SQL Server + some Anti Virus on the server.
Say now you need some more PC for your servers and so your costs go up all the time you need a new server
Sharepoint Server are again from Microsoft and so everything above applies.
I need some help figuring out whether it'd be a good idea to use a CMS or portal solution for my latest project, which is (currently) an ASP.NET MVC application that must serve multiple customers (being a company or some other entity with a list of users) from a single installation (that is, a SaaS solution).
In addition to the core functionality, which includes document management/publishing, I also need to provide basic social features (such as blog, forum, gallery, polls, etc.). However, it is imperative that content is only visible for the customer to which it belongs, and my evaluation of a bunch of CMS and portal solutions has shed little light on whether they support this. They're pretty focused on single-user installations, and documentation on how to integrate with an existing MVC solution is pretty thin.
Essentially I'm looking for some guidance to help me discard dead-end options (the product does not meet requirements, imposes too many restrictions, is not mature, etc.) and find unexplored options before getting too far ahead with the project.
My requirements for the architecture include:
Multi-site support (using a single domain for hosting)
Watertight separation of content between customers
Full integration across components/features
SSO (single-sign-on)
Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
Ease of development and deployment
Custom logic will be written using C# and ASP.NET MVC and any products should support this
I want to stay in control
Solution should offer features but otherwise stay out of the way (for example, not force stupid idioms on me, like insisting on GUIDs for primary keys)
Active development community
No single-man efforts
Recent source control activity
Reasonable levels of documentation and maturity
Does not have to be open source
I have spent a fair amount of time evaluating products and components, which I'll briefly share here:
Umbraco
Does not support ASP.NET MVC (yet, as someone is bound to otherwise comment)
Great community support, active development
Seems to be lots of work to get started
Kooboo
No source activity (no updates for almost two months)
GPL licensed? (need something that allows for closed source applications)
N2CMS
Partial ASP.NET MVC support
Every customer must have a separate domain
Limited source activity (not dead but not vibrant either)
Orchard
Microsoft-sponsored (which means it's likely to be over-architected, code-bloated and slow, although it does have some well known and respected contributors/leads)
Built using ASP.NET MVC
Looks promising feature-wise (but is unlikely to be stable at this stage)
AtomSite
Feels reasonably mature and has decent documentation, albeit with holes
Built using ASP.NET MVC
Limited source activity, single developer
MojoPortal
Looks good for a portal, but probably requires custom logic to be built as modules around the product (I was hoping to avoid that kind of lock-in if possible)
DotNetNuke (DNN), CommunityServer and Microsoft Office SharePoint Server (MOSS)
Definitely not my cup of tea ;)
BlogEngine.NET
Mature and feature-complete
No ASP.NET MVC support
Integration possible but not without lots of Web.config voodoo
Not sure if it supports customer separation
Given the list above I'm leaning towards AtomSite, N2CMS, Orchard or BlogEngine.NET. If I go with the latter I'll be using jitbit AspNetForum, which is a great match for my needs.
I'd probably prefer to use a custom ASP.NET MVC solution and individual components as this is likely to give me the greatest amount of control, but on the other hand, it'll make site theming and integration harder. What combinations have you tried, what worked well and what didn't? Anything important I'm leaving out of my evaluation? Any other relevant advice?
I'd appreciate it if the answers were not simply endorsements of your favorite product or way of doing things, but something that would help me choose or eliminate solution candidates given the requirements outlined above.
With the level of requirements you've specified, I'm personally going to have to lean towards the custom approach. You can hire someone to do the design (view) portion of the site for you, or you can buy a theme off the internet from site designers and customize it to your liking. (Sometimes just having somewhere to start is enough for intermediate level customization).
Multi-site support (using a single domain for hosting)
You're probably going to want to have control of your hosting environment, either a VPS (Virtual Private Server) or a dedicated box. This is still possible on shared hosting but not reccomended.
Watertight separation of content between customers
You'd probably have to spawn a unique app-pool for each customer with thier own services user for 100% seperation.
Full integration across components/features / SSO (single-sign-on) /Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
This is going to be the tricky part. This Example may have some useful insight for you in the development process, but you're going to want a unified login service and have all sites use it or link to it.
Ease of development and deployment
This is where it gets tricky. Development ease comes from your background I think. MVC is definately the right choice in this respect then, knowing a lot about the right ways of going about building a site in MVC will aid in this process. Keep up to date by reading community blogs and listening to podcasts like Hanselminutes or DotNetRocks will help keep you in touch with the newest and greatest tools/technologies for making your site get off the ground quickly and effectively.
Deployment is the tricky spot. MSDeploy still isn't quite there. But if you can you probably will want to come up with a Dev -> Staging -> Release publish structure so you can test your code in a staging (mimiced production) environment.
Custom logic will be written using C# and MVC and any products should support this
I want to stay in control
If you develop the site in ASP.NET-MVC, you'll be able to build common libraries that you can use not just in your site, but also in your custom tooling. This will greatly reduce your code duplication and helps make sure operational unity is achieved. (Everything works the same way).
Solution should offer features but otherwise stay out of the way (e.g. not force stupid idioms on me, like insisting on GUIDs for primary keys)
While you'll have control in this situation, I'd strongly reccomend GUID Primary Keys. This allows Merge Replication, which can help you easily restore backups or use failover DB servers when things go awry.
Active development community
.NET has a great community out there, (including this one) and you should get lots of support if you ask for it politely.
No single-man efforts
Not sure what you mean here, You'd be the Single-Man unless you hire help, but even 2 people can do great things given a little time. Even one-man can do great things, but the framework you're running on here is backed by a commercially funded huge team.
Recent source control activity
Doesn't really apply to .NET, but a lot of the libraries that you may use (NHibernate, MVC Contrib, AutoFac, Etc...) will have lots of activity and constantly being improved.
Reasonable levels of documentation and maturity
.NET and most of the production level libraries developed for .NET (Mentioned above) actually have a pretty good degree of documentation. There's multiple paid & non-paid sources of information for .NET alone, and most libraries (are well supported by the community and known on StackOverflow)
Does not have to be open source
Look for support libraries that are LGPL (i.e. you can use it in commercial software, but if you modify the library you have to release the new library code if you release the binary.) You're pretty safe here, your site dosen't have to be open source if you use these libraries to support your development.
Well, that's my 2cents. The project you've described is no small job, you're looking at a considerable amount of work even if you go with a pre-built solution (mainly hacking it to work the way you want). I imagine your biggest hangups would be SSO & Security for the pre-done solutions. Not to say it's impossible, just tricky and the end result may not be exactly what you're looking for.
Also, look into OpenID, it may be the best solution for linking all your sites together and most pre-built systems can easily be ported to use it.
Take another look at MojoPortal. The CMS is awesome and the main developer , Joe Audette, is very responsive. I'm have several installations of the CMS running single and multiple sites.
I would lean towards a CMS based solution. Having a tested and production ready software not only reduces the development time but also helps in continuous upgrade and reduced bug count.
If you go down this route, you may want to also consider Sitefinity. Not only does it support all the features required by you, but also is built on .NET and supports MVC development. The product is built by Telerik, the makers of UX tools.
Disclaimer: I am employed by Telerik.
I've recently come across phpFox which is a social networking/forums/community site CMS. This may be of use to you and is fairly inexpensive.
The solution for the site of our company has become EBIZ CMS: full-featured site that includes social networking, online store, features a presentation, a forum, create HTML pages and much more, including the maintenance of professional technical support, so we do not even need help for installing by a programmer, and it is only US$ 9/month!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I heard from my peers that knowledge of sharepoint is going to be good for career. We do not use sharepoint at our office. So dont know how to get started. These are my sharepoint newbie questions
Is learning sharepoint worth the effort?
Where are the resources to learn sharepoint?
Is there any reference project I should considering aiming to develop?
Appreciate your inputs.
SharePoint has transformed my career in a such a positive way, I have become a huge advocate/evangelist and have a lot of passion for this technology.
I will say my career/role shift from technical business analyst into systems integration and application development can be almost directly attributed to learning SharePoint.
Quick background - Had previous IT infrastructure experience before I went back to university to get my bachelor's degree. Studied business and MIS, eventually was recruited to work for a company to basically do financial analyst stuff. The company implemented SharePoint version 2.0 soon after I got there. Having some minor exposure to the product previous to my employment, I was put on the project team for the initial roll out. I implemented the first SharePoint portal for that company (and it was a crappy one let me tell you) and I was hooked even with all the failings of SharePoint v2!
Fast forward a few years, now I'm a full time developer, integrating legacy business processes and applications into the SharePoint environment. FAR more interesting than writing pro forma budgets or forecasting maintenance costs...
So I will say this - SharePoint is completely worthwhile to learn.
On Training: There are a ton of training materials available for WSS/MOSS, from end user all the way to architect level.
For an experienced devloper I think the most valuable training you can attend is an administrator's boot camp. Getting such a deep dive into the guts of SharePoint is super valuable, from these aspects:
Server side debugging and troubleshooting efforts on SharePoint apps.
From a solutions engineering perspective: Understanding what can and can't be done in SharePoint and most importantly - why
Having a deep understanding of the OOTB features of SharePoint so you can leverage that functionality instead of recreating the wheel constantly
I hope this helps answer some questions. Good luck!
A lot of companies I have worked for in the recent past have used SharePoint and need customizations for it so I would say yes. Also, apps which run in SharePoint and as a standalone are very handy (and some would say trendy) at the moment.
When customizing SharePoint you should look to building web parts which consume it's API. This is no different than any other ASP.Net web part, save for the API. When I need info I usually look to Scott Guthrie (The Gu) at Microsoft for information. And he did not disappoint this time, here is a blog post with some great articles and links. Scott Gu on SharePoint Web Parts
If you have MSDN (or Tech Net) I believe they have a developer addition of SharePoint. I would load it up and just start playing around. See what the interface looks like and how to make customizations without code changes and then move on to making some custom web parts. Have fun!
SharePoint is embraced by a ton of large companies, and is pretty powerful out of the box -- but as corporations become more dependent on it for day to day business processes, they definitely need customizations. I would say it is absolutely something that is worth learning from a career standpoint. As of a few years ago, a friend at a Chicago-based consulting company told me that SharePoint was their largest growing practice.
For development, for SharePoint 2007 or earlier you need to have access to a full instance of SharePoint server -- which only runs on Microsoft Server OSs (Windows Server 2003 or 2008) most developers set up a virtual machine with Windows Server and SharePoint, then install Visual Studio on it.
With Visual Studio 2010 and SharePoint 2010, the developer story is changing a lot; you can develop and debug web parts on Windows 7, and the Web Part model is much more Silverlight-based. The down side is that corporate adoption of SharePoint 2010 will take some time. You may consider waiting on learning SharePoint 2007 and see if your time would be better spent ramping up on 2010 and using more of your current knowledge.
I am an experienced C# / .NET developer and recently been offered an opportunity to become Microsoft Dynamics (Navision) developer (training, certification etc will all be paid for by employer). I've never been involved in anything to do with this Dynamics so I wanted to ask what is like to be a Dynamics developer in comparison to C#/.NET developer. I have compiled a list of things that I am interested to know before I make that decision. Please feel free to edit the list.
C# / .NET
IDE: Visual Studio
Language: C#
Application domain: web based or desktop based
Business domain: any industry
Good career progression and easy to change job
etc...
Microsoft Dynamics
Relatively closed market (compared to .NET)
Not as many jobs out there
The IDE (or development environment) is terrible compared to Visual Studio, I might even prefer to work in notepad
What benefits does Dynamics customers get in comparison with custom built application?
Thank you!
My own background is as a .NET developer using mostly C# and lately ASP.NET MVC. I've also been a Dynamics NAV developer/consultant/architect for about 3 years now.
The Dynamics NAV world is quite a small one and to be honest it's neither growing nor shrinking. I've heard of a few places recently moving from other ERPs to NAV and just as many moving away from NAV.
I attended a briefing at the Microsoft Executive Briefing Centre in Vedbæk (Denmark) earlier this year and met with the Dynamics NAV GM as well as some Dynamics NAV PMs and developers (i.e. the devs that write the actual NAV app) and the roadmap they have for the product is really exciting - there's going to be a huge focus on HCM and improving some of the financials over the next couple of versions.
In terms of day to day working with NAV it's a bit of a paradigm shift alright. As you mention, the IDE is absolutely terrible. They only added syntax highlighting recently and there's no real intellisense or any of the modern conveniences IDEs today offer. Having said that, you can do some tremendously powerful stuff by combining native NAV objects with add-ins, etc. and they've really improved some of the scaffolding tools to help with development.
Financially, NAV developers do pretty well because they are reasonably rare. NAV solutions architects and consultants do even better. You profile doesn't state where you are but I know in Dublin the starting salary for a NAV developer is around US$60k and in London it's about US$65k.
The job market is much smaller than that for C#/.NET devs but jobs tend to be a bit more secure and there is a growing market for customers hiring in-house NAV devs rather than only partners/providers hiring devs and consulting them out to customers.
I personally wouldn't see it as a binary choice between C# and NAV. Sure, your title may be NAV developer but if you're using some of the later versions of NAV then you may still do a lot of C# development writing add-ins, etc. It's also a fantastic opportunity to brush up on your SQL knowledge as writing/optimising well performing code in NAV requires a reasonably deep knowledge of SQL and how queries get executed handled right the way through the process.
Do you have any more specific questions?
I would always recommend that if you have the opportunity to have an employer cover NAV development or NAV implementation training if your employer is offering to cover the cost of this. As already highlighted NAV is a niche market and Microsoft is aggressively pushing this globablly (I think at last count Microsoft marketing materials showed 70,000 customer sites and over 1 million users on NAV).
I do not think that NAV and .NET development are exclusive in any way - actually if anything having knowledge of both development languages and development environments makes you much more valuable. As of the NAV 2009 R2 Release there are now many more ways that external applications, APIs and .NET can be integrated with any NAV process using any combination of: web services, .NET Controls in the Role Tailored Client and finally accessing native .NET types and classes via .NET Interop. Basically if you know C# or .NET you can use that natively in the NAV environment now. So if you understand the .NET framework and NAV you can utilize the best of both worlds when building any solution for your customers/clients.
Two points I would highlight for any future/current NAV developer (imho):
NET knowledge will be critical in the coming releases as NAV
moves more toward .NET/Visual Studio type integration. As the recent
changes in the R2 release demonstrate they are giving developers much
better tools and if you know both .NET and NAV (C/AL) programming
than you are very well situated to architecht and build best of breed
solutions.
It is crucial that you be able to understand the application
workflow and business logic. Eg. A developer who understands how a
Sales Order works through the various stages of unposted and posted
steps is much more useful than a developer who needs to be told
exactly what to build by a business analysts. While this does take
time if you're new to NAV, make sure that you take the time to
understand and get to know the document structures and transaction
workflow while you are writing your code or building reports.
I know this is getting long winded - but to answer your questions specifically:
The market is opening up as current (and hopefully future) releases
have more integration and .NET connection options. Microsoft is
pushing NAV integration with CRM, online payment processors and web
services.
There may not be as many jobs, but they're global - there are many
in the EU, Australia, New Zealand (I lived there for 2 years and my
employeer paid for the move). North America has much lower NAV
penetration so there are not as many jobs here (but its growing).
So if you want to work and travel this can be great, also as there
is smaller talent pool of specialized NAV resources the laws of
supply and demand dictate that your going rate is higher than a .NET
developer. Here in Canada senior NAV resources can be paid in excess
of $100K CAD (which at todays exchange rate is actully $102K USD).
Yes the IDE sucks! - but it is getting better with each release.
(I HATE this about NAV)
A key benefit (from a back end perspective) is being able to
rapidly develop and deploy business logic and functionality. The
NAV platform has integrated security out of the box and provides
enough structure such that you can develop rich applications very,
very quickly. (I LOVE this about NAV).
Regarding your points:
While .NET is a way of generic development, NAV is a proprietary software for particular purpose (ERP). Hence, the market is pretty closed indeed, you need your development licence to do anything, which in turn requires involvement with Microsoft or being employed with a MS partner. While closed, the market is somewhat, so to say, an elite one..? At least that's how people tend to feel there.
Jobs - maybe not as many in absolute numbers, but NAV people are heavily demanded, and the demand has constantly exceeded the supply for as long as I remember (10 years). Here in Europe you can easily get hired in a week, relocation paid. The jobs are all reasonably paid. Should also note that NAV is a best-seller in Europe, not so much in US, where Dynamics GP dominates.
IDE does not matter. Lacking an intellisense of sorts might be a shock to a newbie, but you get over it in a month or so. Developing in NAV is so easy technically that you don't need a good IDE. What you need instead is a good understanding of how NAV works conceptually, what patterns and data flows are used, and build your things accordingly. The closer you are, the better off you are.
Customer benefits - "best practice" functionality is there on day 1, speed of getting the rest of things done, consistent use of patterns, i.e. "things should work THIS way" (unless the developers create mess by breaking them), avoiding vendor lock-in to some extent, since there are many NAV partners around, and should things go wrong, there is an option to change partners while staying with NAV.
All in all, don't expect either to do much coding with NAV or growing yourself as a tech-developer. Technically, NAV is something between MS Access and a big LEGO of standard functionality and patterns of doing things. What all companies are actually looking for is not technical developers, but developing consultants, as most of the work is typically related to one-off customizations (big and small) as opposed to standard application/module development and releasing versions. So you will be most valuable to your employer once you not only learn to code (which is easily done in 3-6 months), but also understand how the application works, the proper ways of customizing, and most importantly - the do's and dont's and how to go around issues/change requests. Once you can do it on your own with confidence, you're a demanded NAV expert, and may feel, ugh, elite, yet the journey may take 5-10 years, during which you mostly learn the specifics of NAV, a proprietary system.
So the choice is yours. Go for NAV if you feel an ambition to become a valued business IT dev/consultant delivering visible business value. Don't go for NAV if your heart is at things like performance, neat code, version control, algorithms, and top-notch technology.