Utilizzo di Breeze.js senza Entity Framework

Question

Stiamo provando a sviluppare una SPA utilizzando tecniche e tecnologie simili ai corsi Pluralsight di John Papa (ad es. Web API, knockout, jquery, ecc.). Tuttavia, come azienda, abbiamo deciso di non utilizzare Entity Framework. Vogliamo scrivere i nostri layer di dati lato server usando ADO.NET standard.

Ora, stiamo cercando di integrare Breeze nella nostra soluzione. Tuttavia, anche se il sito web di Breeze dice che non sono legati a Microsoft, sembra che se non si utilizza EF, si farà un lungo e doloroso viaggio con Breeze.

Abbiamo provato a valutare l'esempio di NoDB Breeze, ma quella cosa è molto complicata e difficile da capire (oltre a capire come implementarla in un arco a livelli standard sul lato server - tutto sembra essere strettamente accoppiato e è appena messo nella cartella Models di un progetto MVC/Web API).

Quindi, la mia domanda (s) sono:

- È Breeze è la scelta sbagliata per una libreria di dati lato client, se non si sta usando EF?

- Se Breeze può essere facilmente utilizzato per non utilizzare EF e utilizzare direttamente ADO.NET sul lato server, c'è un esempio migliore o una documentazione che mostra come farlo?

- Dato che la nostra implementazione SPA ricorda da vicino arco SPA di John Papa con Durandal, ad eliminazione diretta, API Web, ecc, tranne che (ancora una volta) non stiamo utilizzando EF, c'è una scelta migliore per noi che Breeze?

- E poi c'è SignalR ... Abbiamo in programma di implementare SignalR in seguito, Breeze funziona anche con SignalR?

Grazie!

Answer 1

Ci sono un sacco di esempi più specifici su SO.com, ma voglio affrontare alcune delle vostre domande chiave -

Abbiamo provato valutare l'esempio NODB Breeze, ma che cosa è molto complicata e difficile da capire (oltre a capire come implementare lo standard in un arco a livelli standard sul lato server - tutto sembra essere strettamente accoppiato e inserito nella cartella Modelli di un progetto MVC/Web API) .

A seconda del tipo di database che si sta utilizzando, sono disponibili più altri campioni e le istruzioni disponibili su StackOverflow e su Breeze. Potrei elencarli qui ma se hai aggiunto il tipo di Database che intendi utilizzare potrebbe essere un po 'più facile fornire una risposta migliore.

Breeze è la scelta sbagliata per una raccolta dati sul lato client se non si utilizza EF?

Breeze è una scelta eccellente indipendentemente dal tipo di back-end che si sta utilizzando. Ci sono davvero diversi livelli di difficoltà nel finalizzare il tuo set up, a seconda delle altre tecnologie che stai usando, ma una volta preso il blocco, ti guarderai indietro e riderai di quanto è stato più semplice creare manualmente la tua libreria di dati.Ecco un esempio impressionante della libera informazione che è disponibile per guidare l'utente attraverso la comprensione come utilizzare le varie tecnologie - Why are my Breeze.js entities not creating ko.observables?

Se Breeze può essere fatto facilmente di non utilizzare EF e utilizzando solo dritto ADO.NET sul lato server, c'è un esempio migliore o documentazione che mostra come fare questo?

avrei fatto il check out alcuni degli altri campioni che sono disponibili, a seconda di quali tecnologie si sta tentando di utilizzare. Ecco alcuni esempi che non utilizzano EF -

Zza - http://www.breezejs.com/samples/zza

• angolare, MongoDb, Nodo

Edmunds - http://www.breezejs.com/samples/edmunds

• angolare con No database a tutti , solo consumo API

Un sacco di volte troverai che devi solo usare per digitare nelle tue query per creare entità dalla tua query. A volte devi andare più in profondità, ma di nuovo dipende dalle tecnologie.

Dato che la nostra implementazione SPA ricorda da vicino SPA arco di John Papa con Durandal, ad eliminazione diretta, API Web, ecc, tranne che (ancora una volta) non siamo utilizzando EF, c'è una scelta migliore per noi di Breeze ?

Ci sono altre librerie lato client, JayData è probabilmente il più popolare. Probabilmente hai bisogno di riunire la tua squadra e prendere una decisione su quali tecnologie hanno più senso da usare, prendendo in considerazione molti fattori diversi dai nostri pensieri su StackOverflow.

E poi c'è SignalR ... Abbiamo intenzione di attuare SignalR tardi, non Breeze anche lavorare con SignalR?

Aggiornato con suggerimento di Ward - SignalR e Breeze apparirebbero per servire scopi diversi per l'applicazione. Penso che sarebbe saggio vedere se la tua applicazione funzionerà bene con SignalR in più, piuttosto che se Breeze lo farà, a causa delle loro diverse preoccupazioni.