I'm starting a new personal project on the side, so this is the first time I'll be able to start from the ground up on a larger project since ASP.NET 2.0 was first released. I'd like this to also be a good learning experience for me, so right now I'm planning on building this upon ASP.NET MVC, Castle ActiveRecord, and Ninject. I'm most comfortable with MbUnit for unit testing and CruiseControl for CI so right now they are the front runners.
But what would be your first additions once you click "New Solution"? Open Source, commercial, whatever. I have an open mind if they look like they can make it do what it do.
Web Framework: MVC
Just a better way to make web applications
OR/M: NHibernate
Nothing really beats it in performance or features
Javascript: JQuery
Been using it before it got all cool. JQuery to me seems less like a framework, and more like a natural extension to the javascript language
IoC: Castle Windsor
Most mature of the .net IoC containers
CI: TeamCity
Once you try it, you will never want to go back
Testing: NUnit
They are all pretty head to head in features, I prefer the tooling (resharper) and syntax (been using it forever now)
Mocking: Rhino Mocks
Again, I like to go for maturity, especially in open source projects
In Hanselman ALT.net Geek Code, that translates to
IOC(CW):MOC(RM):TDD(NU):SCC(Svn):ORM(NH):XPP(++):DDD(T+):JSL(Jq):CIS(TC):GoF(++)
Built on nothing. Personally, I'm not a big fan of using frameworks and pre-built components for every single aspect of my project. I like to be in control of all the code, and write all the code myself. You could call it an extreme case of not invented here syndrome. Or you could say, if it's a core business function, do it yourself.
I prefer Microsoft Unity for IoC, for NHibernate make sure you look into Fluent NHibernate and say good bye to the xml garbage!
I wrote my own version of the Web Client Software Factory that leverages Unity instead of ObjectBuilder(1) that's included as I ran into numerous issues with it, at some point it will be blogged about in a series of posts but the source code is already on my site which you can view in my profile.
If your project is for an enterprise in all honesty I would recommend against using the MVC Framework. It's such a large derivation from web forms that you will find many developers that don't live and breathe coding will not be able to use it correctly and you will constantly be fighting to keep the MVC usage correct as most developers will treat it the same way as web forms.
Related
Updated.
Updated the question since it looks little ambiguous and not the answer i was looking for.
We have a huge .NET application running on MVC and angular. It has multiple projects under the main solution. .
We also have a replica of that application in Node.js for front end developers.
It looks something like this :
What happens is - Front end developers make changes in Node js solution (like js or .less files or controller) - make changes and move those changes to .Net solution which is the actual live project.
Off late - we have issues with developers working with two different solutions (Node and .NET) and keeping two copies of assets everywhere.
We ultimately decided to combine them and bring the whole Node.js application into ours .NET Solution as 6th project.
Something like this
Wondering if anyone has previously done so - adding a .NET application with existing Node.js application. If so any pros and cons to consider.
Some points to note - the Nodejs project and .Net project are completely independant of each other. The idea is to consolidate the applications so that We can either run the .net application or UI application from single solution.
Eventually, we will consolidate all the assets to just one project so that - we dont have to do duplicates.
Also, would appreciate any links where I can see how to start merging these two applications.
You definitely want to look at JavaScript Servcies. Building Single Page Applications on ASP.NET Core with JavaScriptServices.
Made for .NET Core, but you can run .NET Core on Full .NET Framework, which should make it easier to migrate to.
What I think you have is, say, a production version in .NET and a development environment in node.js for developers which prefer that.
At the company I work for, we use AngularJS for our front end and .NET/Entity Framework back end and it works pretty well.
I'm not sure if you are integrating some sort of JavaScript back end in with it or not. Assuming you are going to stick with a .NET backend and a JavaScript heavy frontend, it should be fairly easy.
That being said, nothing in this career is truly "easy". I would recommend using an AngularJS frontend as it has seemingly endless functionality.
Some minor suggestions if you choose that route is to check out John Papa's style guide. great reference for writing AngularJS. Make sure you have consistent naming, especially in Visual Studio as AngularJS can be a little moody.
I prefer to bind values to the view when working on AngularJS, e.g.
vm.title = "Data I want to bind"; in the view: <h1>{{vm.title}}</h1>
If that renders as {{vm.title}} instead of Data I want to bind you know something isn't working. I prefer catching it sooner rather than later.
Dependency Injection is another thing to be careful with, the style guide covers it as well. Basically if you minify your AngularJS files and the minifier removes the information required for DI, your project will break. I've been down that rabbit hole a few times.
If you aren't intending on using AngularJS then forget I said anything. I was just exercising my fingers. I hope that helps shed a little light on your decision.
I am exploring technologies and libraries before I get started on a new project. One that has really caught my eye is the S#arp Architecture library for ASP.net MVC. However, I have already decide that the bulk of my web application will use Visual Web GUI as the front end, leaving only a small separate customer facing web component that will be developed in ASP.net MVC. Bearing this in mind, based on the experiences of those of you who have a good familiarity with S#harp Architecture, or may have attempted a similar solution using S#harp, are there any issues or gotchas I should be aware of before I begin? I have also had a look at Castle Active Record, and Fluent NHibernate usage as possible options, but find myself leaning towards S#arp.
My most major goal in choosing a library are to get my data access set up using the repository pattern as quickly as possible.
If your main goal is to flesh out a persistence layer quickly then S#arp Architecture is a bit overload IMO. S#arp makes use of Fluent NHibernate so I'd just go with that. FNH's auto mapping conventions should slice a big chunk off your dev time.
I wouldn't say S#arp is a library. It's more of a boilerplate for Domain Driven Design. You should be familiar with Dependency Injection (aka Inversion of Control), Test Driven Development, Rhino Mocks, and NHibernate before you start looking at S#arp (because those are the concepts and technologies used in it). Otherwise the learning curve will be quite steep.
We have implemented a ASP.NET standard project using the S#harp framework without any problems. I would strongly recommend you start coding from the Services layer and leave no logic in your codebehind aspx files. We do also make big efforts to avoid having logic in Controllers as we saw them as codebehinds files and try to put all the system logic in the services.
Just make sure you plug all necesarry in your global asax file and you should have no problem at all. If you are using NHibernate, Fluent, Service Injection and DDD is really easy to make it work with old asp.net web application.
We are in a situation whereby we have 4 developers with a bit of free time on our hands (talking about 3-4 weeks).
Across our code base, for different projects, there are a number of framework-y type of code that is re-written for every new project that we start. Since we have some free time on our hands, I'm in the process of creating a "standard" set of libraries that all projects can re-use, such as:
Caching
Logging
Although these 2 above would rely on libraries such as Enterprise Library, each new project would write its own wrappers around it, etc, so we're consolidating all these code.
I'm looking for suggestions on the standard libraries that you built in-house that is shared across many projects.
To give you some context, we build LOB internal apps and public facing websites - i.e. we are not a software house selling shrink-wrap, so we don't need stuff like a licensing module.
Any thoughts would be much appreciated - our developers are yearning to write some code, and I would very much love to give them something to do that would benefit the organization in the long run.
Cheers
Unit Testing Infrastructure - can you easily run all your unit tests? do you have unit tests?
Build Process - can you build/deploy an app from scratch, with only 1 or 2 commands?
Some of the major things we do:
Logging (with some wrappers around TraceSource)
Serialization wrappers (so you can serialize/deserialize in one line of code)
Compression (wrappers for the .NET functionality, to make it so you can do this in one line of code)
Encryption (same thing, wrappers for .NET Framework functionality, so the developer doesn't have to work in byte[]'s all the time)
Context - a class that walks the stack trace to bring back a data structure that has all the information about the current call (assembly, class, member, member type, file name, line number, etc)
etc, etc...
Hope that helps
ok, most importantly, don't reinvent the wheel!
Spend some time researching libraries which you can easily leverage:
For logging I highly recommend Log4Net.
For testing nUnit
For mocking, Rhino.
Also, take a look at Inversion of Control Containers, I recommend Castle Windsor.
For indexing I recommend Solr (on top of Lucene).
Next, write some wrappers:
These should be the entry point of you API (common library, but think of it as an API).
Focus on abstracting all the libraries you use internally in your API, so if you don't want to use Log4Net, or Castle Windsor anymore, you can by writing well structured abstractions and concentrating on loosely coupled design patterns.
Adopt Domain Driven Development:
Think of API(s) as Domains and modular abstractions that internally use other common APIs like you common Data Access library.
Suggestions:
I'd start with a super flexible general DAL library, that makes it super easy to access any type of data and multiple storage mediums.
I'd use Fluent nHibernate for the relational DB stuff, and I'd have all the method calls into the you data access implement LINQ, as it's a c# language feature.
using LINQ to query DBs, Indexes, files, xml etc.
Here is one thing that can keep all developers busy for a month:
Run your apps' unit tests in a profiler with code coverage (nUnit or VS Code Coverage).
Figure out which areas need more tests.
Write unit tests for those sub-systems.
Now, if the system was not written using TDD, chances are it'd be very monolithic and will require significant refactoring to introduce test surfaces. Hopefully, at the end of it you end up with a more modular, less tightly coupled. more testable system.
My attitude is that one should almost never write standard libraries. Instead, one should refactor existing, working code to remove duplication and improve ease of use and ease of testing.
The result will be very much like a "standard library", except that you will know that it works (you reran your unit tests after every change, right?), and you'll know that it will be used, since it was already being used. Otherwise, you run the risk of creating a wonderful standard library that isn't used and doesn't work when it is used.
A previous job encountered a little down time while the business sorted out what the next version should be. There were a few things we did that helped
Migrated from .net reoting to WCF
Searched for pain points in the code that all devs just hate to work with and refactor them
Introduce a good automated build system that would run unit tests and send out emails for failed builds. It would also package and place that version in a shared directory for the QA to pick up
Scripted the DB so that you can easily upgrade the database rather than being forced to take an out of date copy polluted with irrelevant data that other devs have been playing with.
Introduced proper bug tracking and triage process
Researched how we could migrate from winforms to wpf
Looked at CAB (composite application) or plugin frameworks so configuration would get simplier. (At that time setup and configuration was a tremendous amount of time)
Other things I would do now might be
Look at Postsharp to weave cross cutting concerns which would simplify logging, exception handling or anywhere code was repeated over and over again
Look at Automapper so that conversions from one type to another was driven by configuration rather than changing code in many places.
Look at education around TDD (if you dont do it) or BDD style unit tests.
Invest time in streamlining automated integration tests. (As this one is difficult to set up and configure manually it tends to get dropped of within SDLC)
Look at the viability on dev tools such as Resharper
HTH
I need a simple MVC framework, without jQuery extensions, hibernate, loggers, etc..
Only Model-View-Controller functions. Anyone have an idea where I can find one?
Does the official ASP.Net MVC framework not meet your needs? It doesn't come with loggers, ORM's or anything like that. And it is extremely flexible and extensible.
Yes, by default it includes jQuery libraries in any new projects you start... but those are simple to remove, and are not part of the framework itself. There is no reliance on them.
If you don't need jquery, then simply delete it from your ASP.NET MVC project.
Two alternative MVC frameworks would be: Vici.MVC, FubuMVC
Other MVC frameworks that haven't been mentioned here:
MonoRail (2.0 was released today)
Bistro (great F# support)
http://asp.net/mvc is the only ASP.NET framework I know off. It's very basic out of the box, and it's up to you what you add to it.
It allows you to add to it whatever you need and doesn't force you to use anything except the MVC design pattern and ASP.NET.
It's very simple in that all you really need to worry about is Models, Views and Controllers.
I second on the Vici MVC framework! Open source, easy to setup, easy to learn, lightweight, powerfull and with a good support channel through a StackExchange-based webpage.
The Vici Project comes with a lot more libraries (e.g. Vici CoolStorage = ORM) which work beautifully together.
Go with ASP.NET MVC. That's about as simple as it comes. If that's too complex, I'd suggest regular webforms or MVC on a different platform (like CakePHP)
I've designed a minimalistic MVC framework for ASP.Net named BarelyMVC. It's BSD licensed and currently at an alpha release.
It gets it's name because it's quite literally barely an MVC framework. It attempts to take all of the magic out of the equation and lets you directly control many aspects of how things work. There are no magical attributes. It consists of a simple stateless authentication system, a statically compiled view system made using T4, and a powerful Router and set of classes for handling HTTP requests. When put together it can make for very clear and easy to read/write code that you know exactly what it does. It also takes a hands off approach to architecture. When something you write doesn't mesh well with the traditional MVC architecture, it's trivial to work around that.
I'm developing a website , job portal. I have 2-3 years of ASP.NET webform development experience,
I want to create a professional job portal site (to improve and learn more) but trying to decide on best architecture. Any suggestions or advice will help...
Thanks
Well, there are a number of ways to answer this question, and I'm sure many others will chime in. I'll just say that since your goal is to improve and learn more, and you already have 2-3 years of webform experience, this might be a good opportunity for you to learn MVC. Then you will have experience in both, and can make more informed decisions regarding the best architecture for future projects.
Happy learning!
Whilst nobody can tell you exactly what to do, the team I manage is about to release a new CMS / Job portal using ASP MVC. MVC gives us excellent testability and scalability out of the box and it can be quickly combined with tools such as nHibernate / windsor (IOC) / nCache / jQuery - this ensures that you have a wealth of resources on the internet to help accelerate your development and skill. You can also embrace standards such as XHTML 1.1 strict, which is almost impossible with ASP.Net webforms due to the auto generated HTML
1 other advantage is that you also get away from the dreaded ASP.Net viewstate.
Use ASP.NET MVC if you want to:
learn the ASP.NET MVC framework
use jQuery or similar libraries
really learn web-languages (HTML, CSS, JavaScript)
use Test Driven Development
have a clean separation of concerns
If you don't have the time or will to learn to use the ASP.NET MVC framework correctly, stick with ASP.NET WebForms.
My answer is almost always "ASP.NET MVC." The amount of flexibility and features and testability and maintainabilty and ... heavily outweigh WebForms.
WebForms has the advantages of a rich ecosystem of existing controls and documentation, and is really powerful for some kinds of tasks (complex, multi-form interactions), but I find its limitations get in the way far too often. You have to mold yourself to it.
It really depends on what the end goal of the application is. As Scott Ewers said, if your goal is to learn, then using ASP.NET MVC will expand your breadth of knowledge in the ASP.NET space (since you already know web forms).
Additionally, if this is going to be a public product, you can leverage the testability benefits of MVC and run automated unit tests. Key ideas like Separation of Concerns can also increase long-term scalability and maintainability.
The primary reason why you might choose web forms is if you are rapidly prototyping the job board application. As you know, web forms allows you to drag-and-drop components onto the canvas to quickly create some basic data entry functionality.
There is a herding code podcast from May 13 on the subject.
Herding Code 47: Joe Brinkman on Webforms vs ASP.NET MVC.
I also agree that choosing MVC would have the advantage of allowing you to expand your knowledge. That not being the only reason, given the choice as well I just finished a small MVC project (my first) and let me tell you MVC rocks! Its a great framework which I feel gives you more flexibility and at the same time out-of-the-box tools to create a web app quickly and painlessly. It was my first experience with VS2008 & .NET FW 3.5 & LINQ, and all the guides at www.asp.net helped me go forward quickly (especially the free tutorial chapter from an MVC 1.0 book mentioned here).
I also got to learn JQuery along the way, as it is very much integrated into these new technologies.
One think to take note though is that this being a new tech, version 2 is already being cooked up, so if your project is for the long run, have that in mind and plan accordingly (in my case, being a small project, I'll probably try upgrading my project to version 2 when its officially released). Yet at the same time, having a fully MS (and thus MSDN) supported version 1 was a godsend for me...
Good luck!
I have good experience in Jquery, CSS, HTML, Javascript but not in TDD.
I have time..and willing to learn MVC but wasn't sure MVC is good choice for Job portal or similar site..
This can be considered a shameless self-advertisement but here is my quiz on how to choose between the two:
http://sietch.net/ViewNewsItem.aspx?NewsItemID=101
I was recently tasked by one of my clients to write a paper, or simply a checklist, that would help other lead developers make this same decision.
I posted the first 2 rough drafts on my blog. I am admittedly pro-mvc but the paper/checklist has been we received so it might be helpful.
http://eric.polerecky.com/archives/a-somewhat-less-biases-comparison-of-mvp-and-mvc/[http://eric.polerecky.com/archives/a-somewhat-less-biases-comparison-of-mvp-and-mvc/][1]
I think the most often overlooked benefit of MVC is convention; I really see any convention in webforms projects and while not strictly enforced in MVC projects at least its there.
i started developing our current app in webforms, mvc wasn't available when development started.. i've chosen the MVP pattern, with URL rewrite HTTP module. currently i'm investigating plugging in some MVC into this, basically to use the front-controller instead of using page-controllers. the other things in already established MVP architecture with web forms in my app give me more flexibility than pure MVC approach without WebForms, which i like, although require a bit more code than MS MVC examples (never tried it for real project to see if it stays that way, like in those examples in screencasts).
what i don't like with MVC is mixing control code inside templates - i believe loops, ifs and stuff like that just shouldn't belong inside the template. but a couple days ago i've ran into Spark view engine that looks kind of promising in that segment, although not still close to the Tapestry 5 (a component-based webGUI framework) in the java world.
But the above mention suggestion to mix both might work for you to explore MVC world and have the safe ground to fallback to if something won't work for you might be ok for you.