I recently started delving in to zend expressive. I know zend makes use of zend db typically. In my project I am developing microservices and was wondering what the opinion is about using doctrine with regards to microservices in zend expressive. Any thoughts or opinions would be appreciated.
There's no general rule forbidding Doctrine in an Expressive project. I'm finishing up such a project this week (a full line-of-business app, not a microservice), and it's gone very well. If doctrine fits for you model, there's no reason to eschew it just because you're writing a small app.
You can use Doctrine with any PHP framework including Zend Expressive. The question you should ask yourself is do you really need Doctrine? If you have to create an application with complex domain logic, then Doctrine is exactly what you looking for. Also, you can use Table and Row Gateways to map your database tables or rows and to interact with your database in a object oriented way. Personally, I would not recommend using Doctrine for small applications with no, or very simple business logic.
Related
I have a single page app built with emberjs with an a rails backend. Is it a common pattern to build an admin interface on rails serverside on a subdomain. What is the right approach for this?
Your question is vague but I will try to answer it my best. I have done this with a Node and a Go backend combined with Ember.js.
No, there is technically nothing to prevent you from doing a single page application for an admin interface.
Rails is a good choice for this, and generally you should stick with the backend framework/language you and your team master the most.
As for what would be the right approach, there is no magic recipes. Document your code, write test and follow best practices for the tools you are using.
One key element though will be the communication between your frontend and your backend. Ember chose to follow the JSON API specification (http://jsonapi.org/) and comes out of the box with an adapter to talk with these kind of API. Using such adapter will help you save a lot of time.
Here are some implementation of JSON API for Ruby : http://jsonapi.org/implementations/#server-libraries-ruby
One more thing about your frontend code structure. You haven't say how big your app will be. If it gets big, you may want to take the pod approach in ember-cli (http://ember-cli.com/user-guide/#pod-structure). It basically changes the structure of the code so it's easier to maintain a lot of files.
I have recently inherited a non-finished web app written in Clojure, based on compojure and hiccup basically. It's a bad attempt to model some sort of MVC with OO style not in the FP style as seen here . So I bet to re-start the project almost from the scratch reusing the useful parts. I consider these alternatives:
The least breaking alternative would be Compojure+Enlive+jquery-pjax
Using a clojure web framework like Pedestal Any experiences about this?
The initial idea was to implement a RESTful API serving JSON so for the more elaborated solution I have Backbone+react.js in my mind for the front-end and Liberator for the back-end but it's likely to take longer to develop than a traditional server app.
Thoughts and alternatives taking into account that an Ajax experience is required please, thanks a lot!
I'm not sure what is the relation between RESTful API and responsive in your post. However ...
You have multiple options here: Pedestal, Liberator and Caribou.
If all what you need is a RESTful API, then I think Liberator is your best bet and it is not going to take longer time as you mentioned. I don't know how you got that impression.
Pedestal shines if you want to develop Single-Page applications but the framework in general requires a good time to grasp and understand how it is works.
Have a look at Caribou also. It is easy to use and feel familiar.
But again, it is your choice.
I write server application in Symfony2 framework using Doctrine2 ORM. Now I need to secure my database from SQL injection. I read about this a little bit and I know that doctrine2 prepared statements can prevent my app from SQL injection attack. But is this secure me in 100%? Is there really no possibility to attack my server app? If there is any way, how can I defence from it?
When you keep using Doctrine everywhere, all your statements will be secured via Doctrine.
I think noone can answer with: "There is a 100% security".
But when there is a known security issue which relates to Doctrine I am pretty sure it will be fixed soon, because there are many users working with it and many developers contributing to it.
I recently starting learning test driven development, namely MXUnit, and I love the idea's behind it. I can understand the idea of using TDD with stand alone CFC's, but when it comes to using it with OOP based Frameworks, primarily FW/1 and CFWheels, I am not sure how to use MXUnit with the framework CFC's (controllers in FW/1 and Models and Controllers in CFWheels).
Does anyone know where I can find some resources on using MXUnit with Frameworks?
I can only talk about F/W 1 here as I have not used CFWheels (some info here in another SO question), but in my opinion framework unit testing can be simplified by proper use of a service layer.
The idea is you test service layer objects using MXUnit and leave the framework controllers (for example in FW/1) very lightweight. Essentially the controllers are just passing parameters to the service layer, getting a response back and displaying a view.
The reasoning is that the framework is the least likely place you'll introduce errors - so concentrate your testing on the service object, i.e. the core business logic of your application.
Interestingly, in other non-ColdFusion frameworks (such as Grails) the framework is not tested, tests are created for your model ('domain classes' in grails that model the data) and your service objects, but the framework is assumed to work fine. The idea there - again - is to keep logic out of your controllers and test your service layer and domain model.
I hope that helps in some way.
Given that gae & django persistence layers are quite similar, I'm wondering whether someone has tried creating a wrapper? Say, could be useful for utilizing django.forms.ModelForm.
Are there any fundamental problems with this?
App-engine-helper provides limited support for this, but you're still dealing with thinly-disguised App Engine models. I'm not hugely familiar with Django's model framework, but the basic issue is that Django's model framework is simply too tied to relational databases to easily move to the App Engine backend.
You can use a variant of ModelForms, built right into the App Engine SDK, though - see here for details.
Django norel is better alternative to app-engine-helper. It is a much better abstraction that supports django queries (well many of them -- there is no JOIN support), foregin keys (no ManyToMany relations, though).
Django norel supports admin app (app-engine-patch doesn't).
What, you mean like the Google App Engine Helper or Google App Engine Patch?
The design of Django models implicitly assumes that you're using a relational database. Unfortunately, Datastore does not support all the features of a relational database. For example, there is no equivalent of a join query in Datastore. General transactions aren't supported either. As such, it would be really hard (if not impossible) to adapt Datastore to work as a drop-in replacement for Django models.
At 4:45 of this YouTube video, Guido Von Rossum briefly describes how you need to rethink the way you design your database to fit Datastore's model. The benefit is that you will be able to scale up very well. At 48:30, someone asks why the Datastore API wasn't designed to be more like Django models. Guido explains that the fundamental differences between Datastore and a relational database make this impractical. 13:20 also discusses this.