Frage

hatte jemand eine Chance, die Javascript MVC-Framework mit ASP.NET MVC zu verwenden?

Im Grunde suche i für Beratung auf einem Weg, um sie zusammen, wenn möglich zu verwenden, mein asp.net MVC-app kann ich nicht loswerden, aber ich würde gerne für die JavaScript / JQuery eine Art Trennung von Sorge verwenden .. .

Jeder verwendet so etwas? Ich versuche, die zwei zusammen Bild, weil asp.net MVC bietet ANSICHTEN vielleicht die 2 wäre unvereinbar .... ??

Oder wäre es besser, nur einen OOP Erweiterung Rahmen für die Javascript zu verwenden und wenn ja ... jemand einen guten wissen, die Seite an Seite mit asp.net Mvc funktionieren würde?

War es hilfreich?

Lösung

Mark, I'm another contributor to JMVC. JMVC is designed to work from raw data services, but it can wear many hats.

It's based on thin server architecture. For example, instead of splitting creating views on both the server and the client, use asp.net to create raw JSON data, then pass it to JavaScript, which will use its templates to generate the final HTML structure.

The advantage is that you've already created a reusable service, and your UI logic is all in one place (the client).

However, you don't have to do things this way. You can decide where the best place to create view data.

If your views are all server side (returning HTML from client requests), you might not even need many JMVC views. You would just use controllers. However, controllers are the best part of JMVC. They use event delegation so you don't have to worry about attaching events!

Here's a post where I talk about our architecture with rails:

http://javascriptmvc.com/blog/?p=68

Andere Tipps

I'm one of the JMVC guys. Yes you can use those two together. We advice using REST services to separate your client/server layers, as it provides the cleanest separation for your data. With REST you'd consume data with your client by making requests for all todos, which would come back as JSON. JavaScriptMVC would then call a callback to your controller, and you'd use a client side template (view) to render the data.

The two are definitely compatible, but it depends on where you want your logic to exist. A thick client has many advantages, including scalability and maintainability.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top