I got my datalayer, business layer ready. Now i want to to implement service layer.
I do not want to implement this layer in wcf ria services. Is there any other way to implement this layer in such a way using wcf, so that I get my model through wcf using js.
For example I have my domain 'Person'. (In domain project). Then in my 'PersonRespository' has
InsertPerson, GetPerson etc. to get and store the 'Person' in database.
Now I want to use asp.net mvc to show the person detais.
So next two layer will be Presentation Layer and service layer and manipulate data on client side using knockout.js and I am stuck on following issues.
Where will be mine Presentation layer will live. I am using asp.net mvc so It should be in model folder of mvc application, Is it wise to copy the same code class (Person) to model folder as well from domain model. Event when they are same.
How I will be able to get 'Person' model class in javascript and able to update it from javascript to database as well.
Is my architecture style is of enterprise level or i am missing something.
Any point to tutorial will be helpful.
If you have any further questions please let me know.
Thanks,
Daljit
Question 1:
No you should not be repeating your code. There is talk about this in the DRY (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself) principals of development.
Question 2:
It is recommended that you serialize your model using a json serializer and send it to your UI. It will be updated etc, and then sent back to the services. Google MVVM pattern in javascript to see how this is done. KnockoutJs is a great start in achieving what you want. Its probably best to check out some examples done in knockoutjs to see what is going on. There are also many examples in MVVM for WPF that might help understanding the pattern at a higher level. I would recommend seeing codeproject.com for indepth MVVM examples.
As far as your layers go, you have many options, but a generic recommendation would be:
1) Presentation must be triggered through MVVM bindings, ie if the binding updates, the UI will then update itself.
2) the asp.net side of things should only update the models when sending updates via ajax to the UI. (not everything needs to be sent via ajax, im not saying that. When it does, it shouldn't also send extra html or js to put in the page).
3) Your models should really come from asp.net to the html page. (this will make things easier later, as the page will only be updated via asp.net models and you won't get items coming from multiple domains, which ends up being a nuisance.
4) Your asp.net site should provide a wrapper for your WCF service, and can foward calls to WCF.
OR
If you didn't want to wrap WCF with asp.net and needed your UI to communicate directly via ajax to WCF (should be a rarer usecase like doing an igoogle like page with widgets, or maybe mobile development with no asp.net interaction, ie full js app) Then you can investigate CORS as an option to go from JS to WCF and JS to asp.net (This is of a hard difficulty, easy to program, hard to get working for WCF as there is very very low documentation on it for in my case non IIS hosted WCF). See this page for information: http://enable-cors.org/
Related
We are starting a major upgrade of a large WebForms application. The logic will be split between AngularJS on the front end and .NET MVC on the back end. What are the criteria about where to put routing? I can put it in RouteConfig.cs on the server and have .NET to be responsible for routing; or I can use ng-route on the client, and use only WebApi calls to the server.
I see pros and cons both ways, and I was wondering if anybody has any decision criteria. Or some articles that I missed (Google has plenty on implementing the routes; but not on the decision to pick one over another).
I would argue for full separation of concerns, so routing on the client. Doing the routing on the client puts the client in control of what is being displayed. The server would only serve the raw data via rest.
This also allows you more flexibility in the future as well. Say in 2 year you want to ditch Angular for the next new client framework. All you need are client developers to implement the UI calling the existing endpoints, the server code would not need to be touched. Want to move away from .NET backend? No problem, just implement the endpoint in the new framework, not client could would need to be changed.
You should use both as your application is large.
let say your screens are divide on the bases of rule.
When Admin will login you will load all files related to that functionality and after that take benefit of ng-view and make that functionality as a single page app.
So in this way you don't need to load all files once. by ng-view you can also share data between different screens.
I want to create a largish ASP.NET MVC Web application. On some pages I would like to utilise AngularJS.
This app will not be a SPA.
At what point does this become a problem? For example at what point does running effectively two MVC paradigms become a headache?
Or is it a case of as long as you have clear delineation between what's using ASP.NET MVC (standard action methods etc) and what's using Angular JS then the two run side by side ok without giving you massive code organisation/maintainability headaches?
Cheers for any wisdom.
I'd love John Papas opinion!
Andrew
Since you are only asking for opinions, I will be happy to share my experience. The two do mix very well, and I think in most cases (at least most of my own development) the .NET side becomes very light weight.
Your .NET Web API Controller becomes a simple call to the Data Layer to populate a model or List(Of T) models. This gets returned as JSON to the Angular service.
From there, Angular takes over all of the logic until you need to perform another CRUD operation. Manipulating, validating, etc. all happens client-side in either the model (for me the Angular service acts as the model in MVVM) or the angular controller (which is really a ViewModel).
It's best if you let your model (Angular service) handle as much business logic as possible and restrict the Angular controller to responding to clicks, input controls, etc.
To sum up, let your .NET server side be very light. Just transport data back and forth to the Data Layer. Let Angular do the heavy lifting. You definitely do not need to be building a SPA to see the wonderful benefits of a JS data binding library, of which Angular is arguably the best of breed.
An excellent blog post that contains [ details of what I've discussed here ].
Good luck!
I use ASP.NET MVC alongside AngularJS for a fairly large in-house application. We don't really use many features of ASP.NET MVC beyond the basic page template and script bundling - so everything from the client-side is controlled by AngularJS and client-side routing - except for some distinctions we've made between 'modules' of the app where we wanted a different ng-app for each, along with different script dependencies.
If you're looking to take advantage of AngularJS on a page-by-page basis then I think you have no problem at all. As long as you reference the scripts (both core AngularJS scripts, and your AngularJS scripts for modules, controllers, etc.) correctly then you can just begin decorating elements with ng-app, ng-controller, etc. and it will just work. You could insert the relevant AngularJS scripts for relevant .cshtml pages using a #section declaration.
It will only be more complicated if you need a mix of server-side and client-side routing. Then it will be a case of carefully constructing ASP.NET MVC routes to deliver the SPA functionality where needed.
In my current project I'm using backbone.js as a frontend technology. Ans I should note that I'm still on MVC3 but ready to move on;) Is it reasonable to create api area as data endpoint for my client part. Of course I can avoid it and leave just a plain controller in non-area, exterior part of my project. What is the best practice?
It is good practice to have a separate area for your client API that your backbone models interact with. Separation of concerns, readability and all that.
I would recommend using WebAPI for your API instead of standard MVC controllers though. It is easy to add via nuget, takes minimal config to set up, and it works well with Backbone's HTTP-Verb based approach to model CRUD operations.
If you are already planning on using WebAPI, then please ignore me! If you can't for whatever reason, then I would still say a separate area is a good approach.
I'm writting an application that has many Ajax widgets (Kendo-UI to be percise). It's starting to get messy to have all those Ajax responses without the standard controllers so I was starting to consider making each entities their own controller. If I'm taking the time to do this, I figured I might as well go foward and do those as WebAPIs since I was planning to do this in a not so close future, but hey, it would be done already...
So my question is: Is it a good practice to use an MVC application's own Web API as a Ajax Widget feeds or is there any reason to stick with standard Controllers?
I've seen some arguments about performance, but I don't think this applies to this situation. I believe it was more of a "Controller calling WebAPI" situation which has obvious performance hits. But since it's already a client side Ajax call, weither it goes into a standard MVC Controller or a WebAPI controller shouldn't change a thing, would it?
Edit
Additional information regarding the project:
I am using Entity Framework for the data access.
I have a repository pattern going on with UnitOfWork.
I am using proper a MVC structure (EF POCOs AutoMapped to DTO POCOs in the repository and fed into View Models by the controllers)
This is a MVC 4 project on .NET 4.0
There is a lot of database relationships (specially for the object I'm working with at the moment)
I don't know about "good practice", but it's certainly not "bad practice". I see no difference whether you do it in the app or a different one.
I think its a good thing but only if what you are doing in the API is kept as generic as possible to other applications and services can reuse the API.
Both the applications I have written and continue to maintain use pretty much the exact same stack as your app.
I have recently re-factored one of the applications to use the API for all the common things like lists that I'm binding to Kendo ComboBoxes etc. in my views. Its a fairly large application that re-uses a lot of the same lists such as states, priorities, complexities across various Entities and views so it makes sense to put those in the API.
I haven't gone as far as going the whole hog through. I draw the line with things like this:
public ActionResult GetAjaxProjectsList([DataSourceRequest]DataSourceRequest request)
{
return Json((DataSourceResult)GetProjectsList().ToDataSourceResult(request), JsonRequestBehavior.AllowGet);
}
That is very specific to how the Kendo Grid wants the data back. Nothing else I have connecting to this app will use this data in this format so I keep it in the controller.
In short... I use the API for common things within the same MVC app and things that I allow to be used by other applications or services, like Excel.
[I've never used WCF before. I've been googling for a couple days and haven't found any info that makes my decision of whether or not to use it obvious to me.]
I've been developing a website using ASP.NET MVC, LINQ to SQL, and SQL Server.
Now I want to develop some mobile apps which will be fed data from the site's DB.
It has been suggested to me that I use WCF for this.
I know that if I have data facing the public internet, it can be scraped if someone really wants it, but I'd like to minimize the "scrapablility" of my data.
Since my mobile apps will probably just be sending/receiving data in JSON format, what benefits would I get from using WCF instead of just RESTful JSON-returning URI's in MVC?
And if I do implement WCF, should my MVC site be hitting those services for data also instead of using LINQ in my controllers?
I've got an ASP.NET MVC application hitting WCF. I originally developed it without WCF by having the controllers interact with a service layer that hits my repositories. A requirement came up during development that required me to physically separate the UI from the service layer.
Adding WCF was a pain in the rear. Things that worked without WCF no longer worked afterwards. For example, the state of my entities was lost upon transmission to/from the service layer making it very difficult to utilize certain features of my ORM (NHibernate). I could no longer retrieve an entity, map a viewmodel to the entity in my controller, and allow NHibernate to determine whether or not an update was necessary.
That said, the challenges associated with WCF were mostly incurred at the beginning. I don't need to revisit the configuration very often and I've gotten used to working with detached entities. I also have the benefit of physical separation and WCF is extremely flexible.
Would I use WCF if I needed web services but not the separation? I really don't know. I would probably try to make JSON action methods work because those are much easier (not to mention more fun). Keeping it simple is still a wonderful principle.
As for your MVC site hitting services? I think it's safe to say that your action methods should be very thin and there should be very little business logic or persistence concerns within your MVC project. Separation of Concerns makes it much easier to adapt and change your application.
I don't see any need for WCF. I'd consider an API area, or controller if the API is small, and deliver the data via JSON from a controller action. I'd refactor the app so that the API and your controllers use the same repositories. If you need to retrieve data via AJAX from your views, you can use the API, but I don't see any point in your controllers using them if they can take advantage of the repositories.