Background
I am coming from 3 tier architecture of ASP.NET background. I have used Unit Tests directly on layers and never tried mocking of layers. All application are developed with EF Database First and separate POCOs and Infrastructure project handles the plumbing work of the application. Applications developed are of small to medium size.
Progress so far
Since I started learning ASP.NET MVC, One of the first questions was to how to create layers for solution. For last 15 days I am learning and hunting for good architecture to learn and follow in this and future MVC projects. I have went through following architecture patterns/sites and found them too complex for my own good. Some of the main concerns
Inherit complexity of the project which makes it difficult to work with for new programmers
Sharp learning curve
Too many unit tests for every layer to test redundant behaviors (minor)
Relatively slow compilation during development
Sites / Project I tried
Sharp Architecture
Onion Architecture
Neard Dinner
Project SiLK (Microsoft)
Main Dilemmas
I found that most common thing among these projects is Repository Patterns and Dependency Injection (IoC). Though I do not have anything against it, I found it hard to maintain and understand projects. I have executed fairly large projects with 3 tier architecture, with so-called "tight coupling" with adequate Unit tests to test the project. I feel architecture will be better off without these involved.
Huge emphasis on TDD and DDD
Concept of loosely coupled is far stretched
Loosing focus on MVC as pattern and dominating architecture with other parts
Required Simple, easy to understand, maintainable architecture for MVC projects
Note: I came across this good implementation structure from jimmy bogard’s Organizing ASP.NET MVC solutions. I would still appreciate any suggestions on this topic.
Background
After so much of looking backward and forward I have settled on using Onion Architecture for my ASP.NET MVC WebAPI project.
In this course I found my self struggling to keep up with new development methodologies and frameworks. Fact is whoever is looking for creating new application based on three tier structure or similar existing structure, need to "let go" and embrace new foundations. Advances in the new development philosophies like TDD and BDD are immense and are nothing but helpful.
Web and supported technologies are different beasts than that I know of. Truth is MVC and MVC WebAPI got developed cause existing Web Forms framework could not keep up with new developments.
Technology Stack
It took time and patience to unlearn and learn. But finally I find myself at new level and with the flow of mainstream developments. Following is final technology stack adopted by me (in no particular order).
Backend
ASP.net MVC WebPI
Onion Architecture
EF database first (cause it was suited for my project)
Generic Repositories
Frontend
Bootstrap UI (as UI design framework and skipped jQuery UI)
Typescript (for strongly typed JavaScript, so no direct JS in project)
AngularJS (as front-end MVC)
LESS CSS (for robust and maintainable CSS, so no direct CSS in project)
Breeze.js (for model binding and change tracking)
Testing
- In process of finalizing
Along with above I have used and created bunch of T4 templates to take care of redundant tasks. I would suggest master yourself in it. It reduces development time considerably. I am still making my mind for some of the tools and project and testing. I will post the finalized stack of it once am done.
Above stack may look comprehensive but I found myself it as necessity to built highly maintainable and responsive web application. As I mentioned before, it takes time, but once you are familiar with it, it makes sense.
Note: Of all, learning curve of AngularJS very steep and you will find yourself going back and forth on decision to use it. But stick to it, its worth it.
#Steven: Thanks a bunch for your link, it really was corner stone for me to unravel mysteries of new Web.
Required Simple, easy to understand, maintainable architecture for MVC
projects
Go for NidoFramework. It is just what you are looking for. It is free, simple, well design code framework with a good architectural pattern.
I must say Nido framework will hit the head of the nail for you for your requirement..
Link: https://nidoframework.codeplex.com
Download from NuGet
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've pretty much worked with Classic ASP for ever since it was released almost.. But i am having trouble adapting to the ASP.NET platform.
I have been suggested by many to move to PHP, since it's spaghetti code (I LIKE SPAGHETTI CODE), and it's just like classic asp.. But learning Apache servers and securing them i heard was another big project to learn by yourself.. And since i know more about MS servers, i prefer to stay with MS.
But, I really want to learn another platform, and i was looking at MVC framework and that MVC 1, 2 or 3 is like spaghetti code? Maybe i'm wrong. I assume MVC3 is the best now?
Anyway, From Classic ASP, which would be the easiest and most difficult to grasp you think? ASP.NET with all the compiling and using visual studio, reminds me of when i used to make apps in Visual Basic, but i really like spaghetti code more than compiling stuff..
If there is anyone who has done this switch over from classic asp before, what did you do and why, how easy was it to grasp the new platform? (Preferrably MVC)
Well, MVC is more like classic asp than webforms is. However, it uses structure and frameworks to reduce spaghetti code and make it more maintainable. You have to apply a lot of new concepts to not fight the framework.
For example, a strong seperation of view, model, and controller. This is not something you would do in classic asp, or even generic php (you can do mvc in php, but it requires more discipline and using frameworks as well).
Bottom line is, spaghetti will always bite you in the long run.
Asp.net supports a mode where you don't have to compile anything, you just edit the files on the server and it compiles them at runtime automatically. This is the so called "Web site" model. However, MVC does not work that way and requires the "Web application" model that does compiling (although you only have to compile code, not markup).
I'm currently smack in the middle of my first large ASP.NET MVC project after (and while still) programming in classic ASP for years. I have also programmed in ColdFusion and I have tried Python as an alternative to ASP.NET MVC.
If you want to stick to Microsoft technology MVC is the closest you will come to classic ASP. Webforms is really Microsofts way to make web-applications similar to application development. Microsoft has tried to abstract away the fact that the web is a stateless medium. However, this results in pretty ugly things such as the viewstate (a hidden form field that tries to keep the state of all form fields) and controls that generate HTML over which you have absolutely no control.
MVC gives you more control, and leaves you to handle the statelessness like classic ASP does.
I have still found there is a steep learning curve though; you will have to learn a lot of new things, if all you ever did was program vbscript/ASP:
C# or VB.Net Syntax
Object oriented programming in general (inheritance, dynamic versus static, etc.)
Concepts such as lambda expressions, delegates etc.
The MVC pattern
Most likely also a data-access technology like LINQ or Entity Framework
I'm still struggling with some of these, but I'm getting there. It does take a lot of work though, and perseverance. Not everything is better or easier than in classic ASP. Especially for me, as I have been using WSC's in classic ASP for years, which enables n-tier applications in classic ASP, and eliminates spaghetti code completely.
As I mentioned, I also looked into Python as an alternative; Although at the company I work for we now switched to ASP.NET MVC, I actually found the transition to Python a lot easier. The only reason we went with MVC is the fact that it seemed easier to get new developers when using C#/MVC. (In retrospect this wasn't actually true, we are having an incredible hard time finding a suitable C# programmer around where we are located)
Mind you, in Python you will still have to learn basic Object Oriented programming, but the implementation is much simpler to use than .NETs and the Python language is (IMHO) more like vbscript than VB.NET is.
Also I liked the fact that I don't have to define the type of every variable/function/parameter. This sometimes drives me crazy in C#; if the type of a function changes, it could affect a lot of other functions and variables, which all have to be changed. Also, the syntax is easier to pick up because the language is simple and there aren't a hundred ways to do the same thing.
You can choose between different frameworks, MVC or non-MVC and you can use Python in a lot of other fields as well (application programming, scripting-for example XBMC).
There are also ORM solutions available like Entity Framework for .NET and I found the one I looked into (SQLalchemy) a lot more powerful, and easier to pick up than EF.
So at work I'm currently learning ASP.NET MVC, at home I'm slowly picking up Python. I suggest you try a very simple project in different technologies, and pick the one you find easiest to get started with.
Hope this helps.
If you like your spaghetti served by Microsoft, try any Windows version that supports IIS7. PHP works perfectly and it's really easy to setup with Web Platform Installer.
With that in mind, there is no real reason you should choose any one web technology over the other. You can mix and match as needed, even within a single app.
If you want to get into MVC, forget about 1 and 2 and go straight to 3. MVC is much closer to the metal than ASP.NET WebForms. With your background in classic ASP, you'll probably like it once you get the hang of it.
Update:
If you're serious about learning either MVC, PHP, Ruby or whatever web platform you like. Get a good book. Sit down, read it and follow along with the sample code. I usually decide what book to buy based on the reviews at amazon.
Then, if you need more info on specific topics, go read authorative blogs on the subject. For ASP.NET MVC you'll probably want to look at blogs from Brad Wilsons and Phil Haack.
I started using Classic ASP back in the days but then moved to WebForms now using/learning MVC 4.
Here are my thoughts.
For me Classic ASP was fun and easy to learn as it was simple and did not have a large learning curve, data CRUDS were not difficult either and it did the job in a fairly efficient but messy manner.
WebForms required a higher learning curve but helped with a lot of 'plumbing' code with drag and drop controls, however these were sometimes difficult to modify and customise.
With MVC I have found it requires a larger learning curve than the other two, this is mainly due to it being driven by HTML5 and client frameworks like Knockout etc. To gain a good understanding also requires one to learn OO patterns, Entity Framework, LINQ, WebApi and initially these I did not find simple to digest.
What is easy for you? What part do you find difficult? Read up about a stateless nature of HTTP and find comparisons between web forms and MVC - this should make few things clear.
Do some reading about MVC pattern in general. MVC is a general term which appeared first time over 30 years ago. MVC in .NET 4 is a variation of this pattern, but we are all used to calling it MVC. Make sure you OO knowledge is up to scratch, as well as knowledge of basic design patterns, mainly SoC (Seperation of Concerns) and SRP (Single Responsibility Principle).
if you want to learn / start with the mvc framework I could recommend you do the Contoso University tutorial or the NerdDinner one ( http://www.asp.net/mvc/tutorials#NerdDinner )
If we will have to chose any one architecture pattern for web application in .Net, which one will be the best, MVC or 3 tier, How to decide ?
Jeevan,
I think you're unfortunately following a train of thought that many developers new to MVC take insofar as you've been 'fed' a belief that the 'M' in mvc (model) is purely a linq2sql flat implementation and that's it for the model. Not so... in our apps we have to cater for a mixture of web/desktop and handheld devices all using various areas of common functionality within them. we therefore have created a 'BLL/DAL' dll with all our business logic that is referenced as the 'M' in our mvc apps. This same 'bll/dal' is used in our webforms apps as well as in our desktop apps. in one current app, we're hooking into an oracle backend with our bll/dal dll and using MVC purely as a RESTful service acting as an intermediary between two legacy systems. given the design of our bll/dal dll, we could just as easily switch that to sqlserver, should (as and when) the business require.
so in a nutshell, the proposition of choosing MVC or 3 tier (and i actually think you are meaning layered, rather than tiered [which relates more to physical separation of functionality/services]) is totally a moot point as they are converging, rather than disparate technologies.
hope this helps - i'll try to source some examples via mr google later today to exemplify the fullness of my approach.
[edit] - from a similar question here on SO;
N-tier just refers to the physical structure of an implementation. These two are sometimes confused because an MVC design is often implemented using an N-tier architecture.
MVC Vs n-tier architecture
in a nutshell, one is object/API design, one is system architecture; both can live happily together.
Both are pretty high level concepts, and with all high level concepts there are no definitive answer. Moreover, you can quite succesfully mix them. For example have multitier application on the presentation tier, provide your application is large enough that this is required(for instance you had large cluster of data + analytics layer + reporting layer).
Everytime you're choosing between those 2, I would suggest thinking about these aspects:
What architecture you and your team feel most comfortable with in order to make a deadline
How complex your application really is and what will be specific benefits of using either of those architectures
What are usage pattern that your system will exercise, and which architectural solution fit address needs of these usage patterns better
How maintainable each solution will be
This list could go on of course, but I think these 4 things will get your on the right track.
From my experience architecture of more or less complex, real life system(that is not academic fantasy ones) is never MVC or 3 tier, but always is quite a mix of many things :)
Simple as it is :
Why to move to Asp.NET MVC & why not to move ( if there is any reason ) ?
Added
Is it a necessity to move ?
Can we say the future belongs to asp.net mvc ?
How many years do you think it can stays on top ?
MVC is much more well constructed, allowes for much better code seperation and control over markup, and is much lighter on the server, that IMHO the only reason not to move is if you have a legacy .NET application (or other) that is working flawlessly, and you're not expected to perform serious adjustments / fixes on it in the near future.
If you do decide to move, you should know that you'll be able to reuse very little of your webforms GUI and user controls, since MVS is built a bit differently. You class libraries you could reuse, if they're written well. In any case, writing stuff in MVC is much faster than in WebForms, even if done from scratch.
also looking at moving at the moment.
the main bonus for me is the complete control over layout. i'm also looking into implementing a restful API which the MVC model works very nicely with because of the path structure.
Josh
If we move for MVC we can add or edit any module so easyly.
So we can add any new module just like a plugin
I patrially disagree with the accepted answer. I have built large applications in both WebForms and MVC and here is my opinion:
ASP.Net Web Forms and ASP.Net MVC are both great frameworks that allow the C#/VB Net developer to build enterprise level applications. Choosing which one to use for your app depends on a few factors. The MVC model has been around for many years, it is well suited if you need more fine-tuned control over the page cycle process and it is also superior when it comes to unit testing etc, because it supports true separation of business logic and presentation layers.
However, do not dismiss Web Forms, the reality is you can continue to use the web forms framework and still have tight control over your page elements be simply moving away from pre-built server controls and integrating HTML5 standard controls. You can take advantage of new JavaScript frameworks like jQuery, you can improve search engine friendliness by using techniques like URL Re-Write, and you can reduce or eliminate post-backs by taking advantage of asynchronous frameworks like jQuery AJAX and SignalR.
The main reason I disagree with the accepted answer is the statement "writing stuff in MVC is much faster than in WebForms" is completely inaccurate. As any developer who has actually built MVC apps will tell you, it's actually much fast to build WebForms apps. The reason is not just learning curve, but the fact that while MVC gives you the benefit of "under-the-hood" access to the page cycle and more direct access to HTML output, is also the reason it takes longer to build MVC apps. Trust me, you will find yourself doing much more "plumbing" work than you ever did with "drag-and-drop" WebForms development.
The fact is, there was a lot of hype when ASP.Net MVC first came out and too many developers assumed it was a replacement for Web Forms. It hasn't. As I stated in the beginningm both frameworks are great, they both have their pros and cons. I would guess that 90% of developers are still building new apps in WebForms.
That's my 2c.
I'd like to build a CMS site based on Asp.Net Mvc and I want to choose my starting point.
I have seen that there is a lot of interest in the new Microsoft Oxite project also if it seems to be pretty early to adopt it in a production project.
I've also looked at S#arp Architecture but it does not properly compare to Oxite as is just a starting point for general Asp.Net Mvc sites.
For me S#arp Architecture has some advantages over Oxite as is far less complex and it uses Nhibernate for the data access layer.
Oxite code uses Linq2Sql for it's DAL and has already a project in the solution that requires the DB version for VS2008.
Oxite seems to me more blog oriented than CMS oriented but I haven’t looked the code deeply.
Here are some of the choices that would point me to S#arp Ar. for starting.
Simple clean architecture
Nhibernate Dal
Community supported
Oxite:
Microsoft project
Potential huge community
Early stages but very good code quality
Provider model that permits to easily switch the DAL
If anyone has looked at the code of these two projects please advice on your opinions.
Thanks
Oxite might be feature rich, but the code quality is very low.
I was very surprised when I checkout the code and found controller actions with 100+ lines of very unclean code, tagsoup views, no unit tests, etc.
The criticism has been well summed up in these blog posts:
http://blog.wekeroad.com/blog/some-thoughts-on-oxite/
http://codebetter.com/blogs/karlseguin/archive/2008/12/15/oxite-oh-dear-lord-why.aspx
As always, it depends on your needs. It sounds like you need something more CMS based. Oxite happens to have some CMS-like features, but it's not really a CMS. It might be in the future as it's a community project, but right now it isn't (all you can do is add content pages).
We're glad everyone seems to like Oxite overall, but it is pretty early. Not to deter anyone from using it in production, because we do. We run MIX Online on it, but totally understand if you're not comfortable with it. We need a stabilization period. At the same time we also need people running it so we can make it stable. Chicken and Egg I'd say. :)
I didn't get much of a response at my question about Oxite here at SO (found at Oxite: What are you going to do with it?), but it is really new so it'll take some time for people to warm up to it and fully check it out. The architecture of Oxite is really easy to get started with; that's its strongest suit.
I'd never heard of S#arp before I read your question so I'll definitely check it out.
Oxite is well detailed already, entirely negatively.
I'll just add that I've been using S#arp architecture for several months and found it very maintainable and flexible. There's also a very solid, growing and active community of users around it.
It is very clean, and quite easily upgraded to Fluent NHibernate RC 1.0
Before I get pointed to one of those 'VS.' questions like below...
ASP.NET webforms + ASP.NET Ajax versus ASP.NET MVC and Ajax framework freedom
Should I pursue ASP.NET WebForms or ASP.NET MVC
ASP.NET MVC Web application vs ASP.NET Web Application
... please let me state that I'm not looking for a comparison.
Some of my concerns that I need answers for include:
Is the learning curve for doing crazy UIs (e.g. having UI for building a BOM tree online) steep? Lots of people posting questions seem to be having problems with some UI requirement or another which has me worried. Is the technology mature enough to handle those type of requirements?
Is there a pretty well developed community and how available is online literature? You can get tons of literature for WebForms.
Would the time to develop it be comparable or less to building a traditional enterprise WebForms site?
How long would it take to get a whole team of developers comfortable (if not enamored) with WebForms to become well versed in ASP.NET MVC?
The truth of it I think is that StackOverflow is Google-like product and ASP.NET MVC might be great for that. But I'm stuck developing software in the Your company's app category.
alt text http://stuffthathappens.com/blog/wp-content/uploads/2008/03/simplicity.png
So taking a plunge could prove very costly later on if something can't be done or it has to be hacked. Hope to hear from those that have taken the plunge.
Thanks.
About 3 months ago, I was told that I needed to develop an enterprise web-app (well, a series of small web-apps actually), but that I could choose whatever technology I wanted.
Since I'm most comfortable with VS/C#/.Net, the dilemma was whether to choose ASP.NET WebForms or ASP.NET MVC2 -- Unlike you, my only background was with Windows Forms (WinForms) and a little WPF. So I had to research (and try-out) both WebForms and MVC.
Just like you, I realized that my app would be neither Google nor Apple like, but your bog standard company app with thousands of buttons and boxes, etc. WebForms seemed like it would be the fastest to deploy, but hard to test and hard to maintain on a long-term basis. MVC seemed to have a much steeper learning curve, but once established, testing and maintenance would be a breeze.
I only fiddled with WebForms for a week, so I can't really comment on it. But MVC is definitely everything I was expecting it to be.
Yes, it's a steep learning curve. Concepts that were new to me:
Model-View-Controller (MVC)
Separation of Concerns (SoC)
Model Binding
Unit Testing and Test Driven Design (TDD)
Mocking and Stubbing
Dependency Injection (DI)
The books that helped me the most were:
Pro ASP.NET MVC2 by Sanderson (MVC, Model Binding, DI, TDD)
The Art of Unit Testing by Osherove (TDD, Mocking, Stubbing, DI)
I also had to brush up on my HTML, CSS, and Javascript.
Overall, there seems to be a fair amount of ramp-up work in the beginning, but maintaining and extending the existing application has been pretty painless. Whenever I've been asked to make changes, it's been fairly easy and I've typically been able to deliver on-time or even sometimes ahead of schedule.
In an ideal world, writing an MVC app would happen with 2 people. One person writing the core code and a second person writing the UI and the Views (HTML, CSS, Javascript.) Although it's entirely possible to do it all by yourself. (which is what I'm doing right now...)
I have run into some hitches deploying in the Enterprise, though. Internally, my company is running Windows Server 2003 and IIS6. Unfortunately, we have been unable to get the app to deploy properly on IIS6 when using Virtual Pathing. (All the references to and in the CSS files are broken.) If you plan on deploying MVC, I would recommend using IIS7 or higher. MVC supposedly works on IIS6, but requires that your IT department be willing to figure out how to get it to work.
Edit: I just realized I never directly answered your questions. Here goes:
My personal experience has said, that, yes, the learning curve is steep for building good Models and UIs, but I'm not really a web-developer so I've been working with that handicap. The good news is that the MVC technology is pretty mature.
Yes, the community is pretty well developed and growing. You'll get a lot of good answers from StackOverflow as well as MS's ASP.NET MVC sub-forum.
I have no personal experience coding WebForms, but I have coded plenty of WinForms apps and I feel like it's taken me approx. 3 times longer to build this MVC app. The initial investment is a bear, but regular maintenance and improvements seem to come WAY faster, especially as the app has grown... Since you seem to have a team of programmers, it may come faster for you guys as you can probably split up the learning/workload.
Again, no prior experience with WebForms, but what I can tell you is that as I was learning ASP.NET MVC, there were times when I was struggling to understand what was going on because I had no prior ASP.NET background. (Example: Membership and Role Providers -- I had to code my own recently. Boy was that fun...) On the plus side, I didn't have any "old ways of doing things" (aka. WebForms) to unlearn either. If you have a team of folks enamored with PostBack / CodeBehind, you can bet that MVC is gonna seem awfully strange at first. But hopefully your team will see the advantages that MVC brings and embraces it fully.
Oh, and it should be noted that you can blend MVC and WebForms. It's not an all-or-nothing proposition. Although, if I were in your shoes, I'd try to embrace MVC as much as possible and only use WebForms where it clearly makes more sense.
Ok, I hope this helps... :-)
I can answer half of your question. I've just dove into MVC from a WebForms background. There is (obviously) a learning curve, but it's really not very steep. I've been able to make the transition with little effort, and I find the whole thing to be a breath of fresh air.
However, I am quite capable with front-end technologies (HTML & Javascript), and I don't like the HTML the WebForms and Microsoft ajax framework generates. If you and/or your team are like this, you will love it. However, if you are proud of the in-depth knowledge you have of the event hierarchy, or if you love the simplicity of UpdatePanels, then you'll probably bridle against the changes.
The documentation is OK, enough to get going happily, anyway. Here's a few videos to whet your appetite:
http://videos.visitmix.com/MIX09/T49F
http://videos.visitmix.com/MIX09/T50F
http://videos.visitmix.com/MIX09/T44F
Here's your documentation home:
http://www.asp.net/mvc/
For a bit more info, the first chapter of the asp.net mvc 1.0 book is online and can be downloaded for free. See ScottGu's blog here:
http://weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx
And, the full code for the chapter can be found here:
http://www.codeplex.com/nerddinner
Finally, in terms of development time, I think it might take a bit longer to develop apps using MVC (although I have no evidence of this), but I think supporting, maintaining, bugfixing and enhancing will take a lot less time. So, with a small up-front investment, I think you'll more than recoup that effort.
Anyway, like I said, these are my preliminary findings. I still have yet to hit a really hairy problem.
As you know its all about the people first, technology 2nd. You can simply build out a new functionality of your company app because they can co-exist, then you can answer all those questions yourself.
It's new stuff so it will of course take more time than what you're used to but heck its all fun so jump right in and start answering these questions for your own people and app.
Interesting that your question focused all on your concerns and not on any benefits. Have you asked yourself the "why" question? If you feel you can be successful with WebForms, why change to MVC? What is there in MVC that justifies the risks? If you were paying for the project, what would you do?
I'm not pitching WebForms over MVC by any means, but as an architect, you need to be able to come back very strong to the question of why you decided to go away from a very well-known quantity to a relatively new one. I think that there are many good reasons to do so, but it not my job on the line. :)