I understand this is a very broad question, but I have worked with various aspects of this problem individually and am struggling to bring all the concepts and technologies together.
I'd like to specify that answers should include these technologies:
- C#
- MVC 3 w/ Razor
- Javascript w/jQuery
Anything above and beyond those (such as Backbone.js, Entity Framework, etc) are welcome as suggestions if they help answer the question which is:
Using the above listed technologies, what is an optimal strategy for organizing code and logic while maintaining scalability and the ability to create a rich, fast, clean UI?
Ideally the focus should be put on a solution being deployed in a business/corporate environment. On that note, the technologies list above will not be changed so please don't offer solutions with "you should be using xxx instead of yyy that you are using now".
Background
I work with jQuery everyday, have adopted ASP.NET's MVC and have been working with C# for a long time. So you can present solutions assuming intermediate-to-advanced knowledge of those technologies.
I'll organize the question into smaller parts to make it simpler to respond to:
1. Project structure
Given I am working with ASP.NET MVC (in Visual Studio 2010) I would like a directory structure solution that offers some acceptance of the main layout this type of application. Something like Brunch I suppose, but with a little more detail of what each folder would contain and how it works with other areas of the app.
2. Data access
I'd like to modularize my data access as much as I can, with an API-type structure. You can assume lots of POCO objects (User, UserGroup, Customer, OrderHeader, OrderDetails, etc), but there will also be some complex reports that require data intensive SQL and careful UI rendering. EF + LINQ are fantastic for the former but not so much for the latter. I can't find something that seems to fit both scenarios without being overly complicated or overly simple.
3. Client-Side Code Organization and UI Rendering
Like most developers first picking up jQuery, I fell into the trap of mashing together code wherever it needed to go but quickly found it piling up and turning ugly. Although I've come leaps and bounds since then, I still struggle with modularizing my code and working with various parts of the UI without repeating code.
As an example, a typical piece of code I might write would look like this, I have commented the stuff that bothers me (note that I've since changed to using deferred AJAX calls and separated the actual data requests from the DOM manipulation):
$('#doSomethingDangerous').click(function () {
// maybe confirm something first
if (confirm('Are you sure you want to do this?')) {
// show a spinner? something global would be preferred so I don't have to repeat this on every page
$('#loading').show();
// maybe the page should notify the user of what's going on in addition to the dialog?
$('#results').show().html('<h2>Please wait, this may take a while...</h2>');
$.ajax({
url: 'blah/DoDangerousThing',
success: function (data) {
// The results will be loaded to the DOM obviously, is there a better way to pull this type of specific code out of the data access calls?
$('#results').empty();
$('#results').append('<b>' + data.length + '</b> users were affected by this dangerous activity');
$('#results').append('<ul>');
// I've recently started to use jQuery templates for this sort of logic, is that the way to go?
$(data).each(function (i, user) {
$('#results').append('<li>' + user.Username + '</li>');
});
$('#results').append('</ul>');
// Need to hide the spinner, again would prefer to have this done elsewhere
$('#loading').hide();
}
});
}
});
General Questions
- Client MVC vs. server MVC? My project is already a server-side MVC structure, so is there still a need for client MVC like Backbone.js provides?
- Should Javascript files get created for each object (like an
OrderHeader.js) and then minified/merged during the build? Or should there just be anOrder.jswhich has logic forOrderHeader, OrderDetails, Reportsetc? - How should complex queries be handled? Right now my leading theory is
/Reports/Orders-By-Date/or something along those lines and I use a custom SQL query that renders a custom dataset (orViewModel) to the Razor View. But what about paging, sorting, etc? Is this better to be done client or server side? (assume larger dataset – 2 to 3 second SQL query) - I've read through Microsoft's Project Silk. Is this a good way to go? How does it compare to Backbone.js or others?
- I'm very accustomed to an N-tiered architecture, do these concepts somewhat throw that out the window? It seems MVC is like a bunch of mini N-tiered sections within what would have been the front-end or top tier in the past.
Again the more specific your answers are the better they will be. I've read a lot of high level documentation and examples, I'm trying to better understand translating it into real world examples.
Best Answer
TerryR my friend, you and I should have a drink. We have some similar problems.
1. Project Structure: I agree with Eduardo that the folder structure in an MVC app leaves something to be desired. You have your standard Controllers, Models, and Views folders. But then the Views folder gets broken down into a different folder for each Controller, plus a Shared folder. And each Views/ControllerName or Views/Shared can be broken down into EditorTemplates and DisplayTemplates. But it lets you decide how to organize your Models folder (you can do with or without subfolders & additional namespace declarations).
God forbid you are using Areas, which duplicate the Controllers, Models, and Views folder structure for each area.
This means if you are working with something like a WidgetController, you have to look in other folders to find the related WidgetViewModels, WidgetViews, WidgetEditorTemplates, WidgetDisplayTemplates, etc. As cumbersome as this may be, I stick to it and don't deviate from these MVC conventions. As far as putting a model, controller, and view in the same folder but with different namespaces, I avoid this because I use ReSharper. It will squiggly underline a namespace that doesn't match the folder where the class is located. I know I could turn this R# feature off, but it helps in other parts of the project.
For non-class files, MVC gives you Content and Scripts out of the box. We try to keep all of our static / non-compiled files in these places, again, to follow convention. Any time we incorporate a js library that uses themes (images and or css), the theme files all go somewhere under /content. For script, we just put all of them directly into /scripts. Originally this was to get JS intellisense from VS, but now that we get JS intellisense from R# regardless of placement in /scripts, I suppose we could deviate from that and divide scripts by folder to better organize. Are you using ReSharper? It is pure gold IMO.
Another little piece of gold that helps a lot with refactoring is T4MVC. Using this, we don't need to type in string paths for area names, controller names, action names, even files in content & scripts. T4MVC strongly types all of the magic strings for you. Here's a small sample of how your project structure doesn't matter as much if you're using T4MVC:
2. Data access: I have no experience with PetaPoco, but I'm sure it's worth checking out. For your complex reports, have you considered SQL Server Reporting services? Or, are you running on a different db? Sorry I'm not clear on what exactly you are asking for. We use EF + LINQ, but we also put certain knowledge about how to generate reports in domain classes. Thus, we have controller call domain service call repository, instead of having controller call repository directly. For ad-hoc reports we use SQL Reporting Services, which again isn't perfect, but our users like to be able to bring data into Excel easily, and SSRS makes that easy on us.
3. Client-Side Code Organization and UI Rendering: This is where I think I may be able to offer some help. Take a page from the book of MVC unobtrusive validation and unobtrusive AJAX. Consider this:
Ignore the ajax success function for now (more on this later). You can get away with a single script for some of your actions:
The above code will take care of the confirmation, showing the spinner, showing the wait message, and hiding the spinner / wait message after the ajax call is complete. You configure the behaviors using data-* attributes, like the unobtrusive libraries.
General Questions
- Client MVC vs. server MVC? I didn't try to librarify the actions you took in the success function because it looks like your controller is returning JSON. If your controllers are returning JSON, you might want to look at KnockoutJS. Knockout JS version 2.0 was released today. It can plug right into your JSON, so that an observable click can automatically bind data to your javascript templates. On the other hand if you don't mind having your ajax action methods return HTML instead of JSON, they can return the already-constructed UL with its LI children, and you can append that to an element by using data-myapp-response="results". Your success function would then just look like this:
To sum up my best answer for this, if you must return JSON from your action methods, you are skipping the server-side View, so this really isn't server MVC -- it's just MC. If you return PartialViewResult with html to ajax calls, this is server MVC. So if your app must return JSON data for ajax calls, use client MVVM like KnockoutJS.
Either way, I don't like the JS you posted because it mixes your layout (html tags) with behavior (asynchronous data load). Choosing either server MVC with partial html views or client MVVM with pure JSON viewmodel data will solve this problem for you, but manually constructing DOM/HTML in javascript violates separation of concerns.
- Javascript file creation Apparently minification features are coming in .NET 4.5. If you go the unobtrusive route, there shouldn't be anything stopping you from loading all of your JS in 1 script file. I would be careful about creating different JS files for each entity type, you will end up with JS file explosion. Remember, once your script file is loaded, the browser should cache it for future requests.
- Complex queries I don't consider having feature like pagination, sorting, etc, as being complex. My preference is to handle this with URL's and server-side logic, to make the db queries as limited as needed. However we are deployed to Azure, so query optimization is important to us. For example:
/widgets/show-{pageSize}-per-page/page-{pageNumber}/sort-by-{sortColumn}-{sortDirection}/{keyword}. EF and LINQ to Entities can handle pagination and sorting with methods like .Take(), .Skip(), .OrderBy(), and .OrderByDescending(), so you get what you need during the db trip. I haven't found the need for a clientlib yet, so I honestly don't know much about them. Look to other answers for more advice on that.- Project silk Never heard of this one, will have to check it out. I am a big fan of Steve Sanderson, his books, his BeginCollectionItem HtmlHelper, and his blog. That said, I don't have any experience with KnockoutJS in production. I have checked out its tutorials, but I try not to commit to something until it's at least version 2.0. Like I mentioned, KnockoutJS 2.0 was just released.
- N-tier If by tier you mean different physical machine, then no, I don't think anything goes out any windows. Generally 3-tier means you have 3 machines. So you might have a fat client as your presentation tier, that runs on a user's machine. The fat client might access a service tier, that runs on an application server and returns XML or whatever to the fat client. And the service tier might get its data from a SQL server on a 3rd machine.
MVC is one layer, on 1 tier. Your controllers, models, and views are all part of your Presentation Layer, which is 1 tier in the physical architecture. MVC implements the Model-View-Controller pattern, which is where you might be seeing additional layers. However, try not to think of these 3 aspects as tiers or layers. Try to think of all 3 of them as Presentation Layer Concerns.
Update after pres/bus/data comment
Okay, so you are using tier and layer interchangably. I usually use the term "layer" for logical / project / assembly divisions, and tier for physical network separation. Sorry for the confusion.
You will find quite a few people in the MVC camp who say you should not use the "Models" in MVC for your entity data model, nor should you use your Controllers for business logic. Ideally your models should be view-specific ViewModels. Using something like Automapper, you take your entities from your domain model and DTO them into ViewModels, sculpted specifically for use by the view.
Any business rules should also be part of your domain, and you can implement them using domain services / factory pattern / whatever is appropriate in your domain layer, not in the MVC presentation layer. Controllers should be dumb, though not quite as dumb as models, and should give responsibility to the domain for anything that requires business knowledge. Controllers manage the flow of HTTP requests and responses, but anything with real business value should be above the controller's pay grade.
So, you can still have a layered architecture, with MVC as the presentation layer. It is a client of your application layer, service layer, or domain layer, depending on how you architect it. But ultimately your entity model should be part of the domain, not models in MVC.