I'm in two minds at the moment in terms of adopting a persistence framework for CRUD operation (for MySQL) with JSF 2. I've googled and read comments from pro-JPA vs pro-JDO groups but I still can't decide what to adopt.
Is there any good step-by-step tutorials (similar to those provided at balusc.blogspot.com) of JPA implementations (Hibernate, etc) and JDO implementations (DataNucleas, etc) available online? Perhaps going through these examples might help me to understand a bit more about these two Java specifications and decide which to adopt finally.
I'm a newbie when it comes to JPA and JDO implementations so please be kind in your responses -:)...
P.S: Please no reference to roseindia.net. Sorry, that site is just too crappy for me!...
Here is the link with maven archetype that should get you up to speed really fast.
http://www.andygibson.net/blog/projects/knappsack/
I suggest trying to use this one:
jee6-servlet-minimal-archetype
It gets you CDI+2.0+JPA
Related
Okay. I'm NOT asking which one is better. I know Yii is not better than Symfony, Symfony is not better then Yii.
I'm asking which one should i go with it.
I want to give some points:
I have a large project which is very-well formatted and very-well coded. If you seen my codes you would think that i made my own framework but its not. It just that very-well coded. I'm using custom made Controllers for HTTP requests.
All i want to do is make my code much more easier to use and much more easier to understand and easier to edit. Component by component editing and extending.
I'm also using Zend Framework as a component but not framework base.
So, as you developers, which project framework for base coding do i really go with it. Yii or Symfony?
I actually loved Yii but Symfony's Bundle systemn and Namespaces are attract me. But i really wonder which one should i go.
As i said, im not asking which one is better. I want to get your throughts regarding to this issue.
I'm open for suggestions. Give me a path.
Yii is probably the truest 'framework' of all the options - it provides the scaffolding you need with almost no assumptions about how you would prefer to implement anything (except perhaps the inclusion of jQuery). It is incredibly fast to develop with, and very very fast to execute which translates to excellent scalability.
Projects I have used Yii for have always ended up well ahead of schedule - Yii just seems to make sense in the way it works. My experience with Symfony is limited, I will admit, but compared to Zend Yii is a breeze. The Gii MVC generator is a fantastic head start too, generating models and basic CRUD code from your database tables.
ALl this is just my opinion from my own experience, but that is what you asked for :)
I think what you search is to see what is the recommendations more than any Evangelism.
Just to give some pointers about what is the current state of PHP, and nice components that is using the latest php features.
Requirements
Make sure what you use has, a way to...:
send to the log (Monolog is a good one)
parse text only config (YAML is a good one)
logic-less templating, with some convention (Mustach, Twig)
dependencies definition manifests (Composer is the way to go, very similar to package.json that Node offers)
define common "service" instantiation mechanism (DependencyInjection is one example)
abstracted way to load libraries (ClassLoader component is a good one)
Localization management (see Symfony2/Twig documentation )
abstract database calls without hardcoding database vendor specific (Doctrine2, Propel)
Unit testing structure, usage and conventions (PHP Unit, Behat, Mink)
Database code doesn't use "mysql" and istead uses mysqli
And all of that distinct functionality packages that you can mix and match.
Mix and match
There is some efforts underway that address this exact issue, here some interresting ones:
The PHP Framework Interop Group is a consortium of contributors representing frameworks and they created some standards, namely the three layers known as PSR-0, PSR-1 and PSR-2
PHP The Right Way is a collaborative work on what is the current best practices.
Tobias Schlitt's definition of a framework
Hope this helps you. with your own choice of which framework to invest on.
Since you already use Zend, why not using it as a framework ??
And there is no anwser to your question, it depends on project needs...
Symfony should be use on 'big' projects with fast servers.
Yii is still a 'light' framework, but is very fast compared to Symfony, and has a short learning curve...
...etc
I've been seeing a lot of articles and references about how to use this patterns for my first (please keep this in mind) serious project with ASP.NET MVC 3 and EF.
The project is not so big (13 tables) and it's basically a CRUD maintenance: organisations that have some users; users that can belong to a group and can create some work areas and templates... Nothing complicated. The point is that this will be the first of a project series and I'd like to create a base to work with.
My questions are:
Which of the previous patterns is the best? Does it depend of the project size?
My models would be these:
Unit of work
Dependency Injection
Do you think they are good enough and appropriate for my project?
I appreciate all your comments.
Serious application doesn't mean to be complex at first sight.
Over engineering an application upfront can be a real disaster, especially if you don't grasp all the technologies involved.
My advice would be to keep it simple. Create a basic application that fulfill requirements (get the thing done and make your boss happy) and then add new concepts along your learning path.
That doesn't mean I promote bad code, no way! Keep your code clean, well organized, etc. But don't be killed by the fear of doing something wrong.
It's normal for a developer to look back to an application made a few weeks ago and then realize that he did some shitty stuff. That's how we progress!
Last but not least, have FUN!
ASP.NET website provides usefull resources to learn the framework and all related guidances. There are a few application samples created step-by-step.
ASP.NET MVC was built with Dependency Injection in mind.
If you want to give a chance to your code to be loosely coupled and easier to change in the future you have to follow the patterns like Dependency Injection, Repository (for presistance abstraction), and UoW (for transaction abstraction).
So my answer is, you should learn about them in the first place to decide after if you want or no to follow the best practices. Even for simple project it's good to apply these patterns because often it gets bigger and bigger. and it's easy to do it in MVC so why to avoid it ?
There is many resources around to learn about. You can just google it.
I would like to answer this question in more generic way. Creating something which can be used in future is difficult than what it seems. All the pattern above can provide you infrastructure pieces to come up with some base framework.
But I would strongly suggest you to look at S.O.L.I.D principals (DI being part of it) to understand some qualities of good code. These are applicable irrespective of the technology involved.
You cannot predict the future requirement of a product\framework, but following these principle you can be better prepare to handle any future modification to the software
You might want to check out S#arp Lite which has many good examples of how to implement the things you want and can serve as a very good base on which to build something quickly.
None of the mentioned patterns are mutually exclusive. You should use the patterns that make sense based on what you are trying to accomplish, not attempt to shoehorn your application design into someone elses idea of how it should work. Sometimes trying to bend your scenario to fit a particular design pattern / practice is the worst thing you can do.
Want to make sure good unit test coverage / do TDD / ensure loose coupling? Then Dependency injection is your friend, as is the Unit of Work pattern. This is definitely a good idea for creating a maintainable, scalable application, but you can go too far with it for a small-scale application.
Need a centralized caching strategy for your data source? Then use the repository pattern. Or an ORM like NHibernate, which might do it for you.
The question is in the title.
It doesn't favor one over the other at all. It's just common to use LINQ to SQL examples because they are simpler to setup and deploy, so it's easier to digest the sample code without getting distracted by something which deserves its own learning path.
I agree that it does not favor one over the other. I always assumed that Linq to SQL tended to be used in examples because it was released about a year earlier. Therefore, book writers were more familiar with Linq to SQL and/or felt it was more stable.
I agree with Rex in that it makes more sense, when giving a tutorial about ASP.NET MVC, to keep other technology decisions simple. Since either DAL implementation can be used, it is easiest to teach MVC by using Linq to SQL (the simpler of the two). Linq to SQL is also widely considered to be more light-weight.
I must admit, it would be nice to have more open-source examples of projects using ASP.NET MVC along with Entity Framework. I can tell you that it works fine, because I am using it on one project. However, it can be a bit more difficult to figure out some of the ideosyncrasies. Here is another question that shows some links to examples.
I think this tendency to use the path of least resistance in example is a diservice to new developers. How many times have you seen an example, with the caveat that it is not production worthy code, with no reason as to why it is not appropriate, or good direction on how to find what is best? Personally, I appreciate longer examples that actually lead me to discover how something should be used are more helpful.
In this particular case, using Linq to Entities would be much more useful, as it is seemingly the future.
In my opinion, it doesn't favor it. It's what you see in most examples, because Linq to Sql is the fastest way to get examples up and running. Rails follows the same convention of many examples using features (scaffolding for example) that you would rarely see used in a production site.
As all the other posters have said - L2S samples are just a lot easier to put together hence you'll see them quoted more. In reality your MVC models may not use L2S directly - they could be hooking up to a separate services tier or some data transfer objects exposed by another system entirely.
I'm trying to find some best-practice examples (or any examples, actually) of using Machine.Specifications with the ASP.Net Entity Framework in an MVC project.
Not having had much experience with Machine.Specifications, I'm keen to see what sort of tests other people find useful and whether there are any gotchas for using the EF-generated objects instead of custom-built ones.
Pointers, suggestions and examples much appreciated.
This is the blog post that got me started using machine.spec, http://blog.wekeroad.com/blog/make-bdd-your-bff-2/
Rob, goes through the complete setup, from installation to writing specs. It doesn't use EF, but it should still get you headed in the right direction. I used SubSonic in my learning project.
I'm a Java developer trying to learn Grails, and I'd like to get exposure to as many parts of the Grails framework as possible. Preferably doing so by solving small real-world problems using the "Grails way to do it" (DRY, convention-over-configuration, and so on).
Three example could be:
Learn about GORM by creating a few classes (say Movie, Actor, etc.) and relations/mappings between them (1:1, 1:N, N:N, etc.).
Learn about the layout support (sitemesh) by using it to generate headers and footers common to all GSP:s on the site.
Learn about the filter support by using it to make sure all accesses to a certain controller comes from authenticated users.
My question goes to all Grails developers out there - what would you include in a "Grails curriculum" and in what order?
All input appreciated!
Here's some examples, but be warned that they're fairly trivial and don't really show you how the system works together. One of the strengths of Grails is that the different parts all combine to reduce your code complexity and speed development. I recommend doing a single project of moderate size (like blogging software or a photo gallery) that forces you to touch virtually everything. I'm currently working on a ticket management application, and I've had to learn basically everything in the framework. It's really not that much material, actually.
That being said, here's my list of "must study", along with some examples:
Groovy, especially closures, maps, and properties. If you're coming from Java, closures might seem a little strange at first. However, once you wrap your head around them, it'll be hard to go back to a language that doesn't use them. Maps and properties use ideas that might be familiar, but the syntax and usage is different enough that it's worth studying them closely. Grails uses these three things ALL THE TIME, all throughout the framework. For a good example, examine the "BeanBuilder" that instantiates the Spring beans defined in resources.groovy. Also, run through the Groovy documentation at groovy.codehaus.org. A couple of hours there will save you DAYS down the road.
MVC programming. The "MVC" model in Grails pretty closely matches the one used in Rails, but it's significantly different than the "MVC" model used in Java desktop applications. Basically, all incoming URL requests are a message to a controller, which returns a view. Domain objects are the data that you want to store, view, and manipulate through views and controllers. Do an input form that validates the user's input using constraints, and then manipulates it somehow using a controller. Something like a page that takes in your birthday, and returns your Zodiac sign and Chinese Zodiac animal. See if you can get it to return errors to the user when bad input is given.
GORM. GORM is super-important, but you'll be forced to learn it with virtually any project you pick. Give the documentation a once-over, just so you know what its' capabilities are.
Filters and Services. These are "the grails way" to do a lot of DRY programming. Authentication is a canonical example, and it's perfect for learning filters. For services, write something that will send out email. There's a great example of a simple emailer service on the Grails website.
Groovy Server Pages. If you've worked with a templating engine before, then this should seem familiar. Get to know the GSP tag library, it's a huge help. Practical examples include: virtually anything. Every application needs a front-end. Try and make it pretty. NOTE: This spills into a lot of stuff that isn't Grails-specific, like JavaScript, CSS, etc. Unless you have that knowledge already, prepare for a bit of a learning curve.
Your "conf" directory. Get to know every file in there, especially UrlMappings.groovy. Play with UrlMappings so that you have an app that takes meaningful information from the URL. Something like /myapp/calculate/36/times/145, where the app returns an answer.
I'd say those are the basics, but there's a lot of other topics like webflows, i18n, testing, session handling, and so on. The best way to learn those is by building a decent sized project. While you're doing that, you'll probably find yourself thinking, "Gosh, I wish that Grails did ____". Read through the excellent documentation on Grails.org, and you'll probably find a built-in capability or plugin that does what you want. The reference PDF lives on my desktop, and I've found it invaluable during my learning experience.
Oh, and look at the scaffolding code that Grails generates. You'll probably end up pitching it all out, but it'll give you a good idea of how the system works.
Have fun, and happy hacking!
Step 1 - Learn Groovy
If you already know Java, I highly recommend Programming Groovy. It's a lot more concise and up-to-date than the otherwise excellent Groovy in Action. Neither of these books cover the significant language changes in Groovy 1.6, so you should also read this page.
Step 2 - Learn Grails
The Definitive Guide to Grails is probably the standard Grails reference - make sure you get the second edition. Grails in Action is slightly more recent, but I haven't read it so can't comment further on it. I found TDGTG a little lighton GORM, so you might also consider checking out Grails Persistence with GORM and GSQL. It's a very short book, but worth it's weight in gold.
Step 3 - Dive In
Try and modify the sample app in the Grails book, or build your own from scratch. The Groovy console is a great way to experiment with snippets of Groovy code.
If the audience is not familiar with programming in Groovy there should be an introduction to that. Java will work but it gets the juices going when you see how less verbose the code is in Groovy. When discussing GORM include constraints and how they influence validation. Scaffolding is a real time saver when starting a new project so be sure to include it. One of the features of Grails that really has helped me is Plug-ins. Pick a few and show how they provide solutions while saving development time. A security plug-in would fit right into the filter topic you mention. Testing, can there ever be enough testing?
I would really recommend reading the Definite Guide to Grails, Second Edition. It covers everything you need to know about writing applications in Grails. It probably lacks the "what happens under the hood" knowledge, but you should get the hang of it. You can buy it as a PDF and start reading it immediately.
You should also have a list of plug-ins to use - Grails has some really nice ones that come in handy. I can tell you some of the ones I use, but that may be a good question here, too. :-)