I've been using Doctrine since about 2007. I recently picked up Symfony2, which includes Doctrine 2, and from my perspective, Doctrine 2 is significantly worse than Doctrine 1.
One thing that seems particularly dumb is that I have to do something like this just to retrieve a certain record:
$em->getRepository('VNNPressboxBundle:School')->find($id);
In Doctrine 1, I believe I would have done something like this:
Doctrine::getTable('School')->find($id);
The verbosity is not what bothers me. The problem is that any place I want to do anything to do with the database, I have to have an $em available. This means I have to have a ton of methods like this:
public function foo($em, $something, $somethingElse)
{
}
public function bar($em, $thing)
{
}
public function baz($whatever, $whateverElse)
{
}
It feels wrong to drag these $em instances around. It's also irrelevant to what the method really does. Further, I have to remember, every time I call a method, "Does this method need an $em or not?" It's totally lame. I want to know if I'm doing this wrong or if this is just the way they want you to use it. It certainly feels wrong.
Unfortunately, what I've read of the Doctrine docs seems to be heavy on practice and light on theory. Where can I find some good documentation on the design decisions behind Doctrine 2?
It seems like if you want to understand Doctrine 2, it helps to understand a little bit about Service-Oriented Architecture and Dependency Injection.
Related
What strategies have Perl people used when mocking Moose objects that they will inject into other Moose objects as type-constrained attributes?
Test::MockObject::Extends doesn't seem to play well with Moose. I need the object to blessed as a specific package though so a vanilla Test::MockObject won't work. I'm sure other folks have had similar difficulty. How did you resolve it?
Extra Points for Solutions that are already on CPAN.
Well I'm not the expert on such things but the first thing I'd look at is Shaw Moore's (Sartak) Test-MockOO.
If this doesn't work for you, I'd then look at using the power of the Metaobject Protocol and starrt manually building Mock objects. Look at Class::MOP::Class and Moose::Meta::Class for how to override specific methods and/or create entire classes at runtime programatically.
If this still doesn't work for you, I'd swing past IRC and ask. The moose hevy hitters hang out there and I'm sure one of them has run into this situation.
bit of a self plug, but I wrote http://search.cpan.org/~cycles/Test-Magpie-0.05/lib/Test/Magpie.pm, maybe you'll find this useful. A mock created with this acts as any class, and does every role possible. It doesn't mock a specific object or class at all. Sadly CPAN's search is a bit rubbish, so searching for "test mock" doesn't show it in the results.
I should also mention that the documentation doesn't contain a huge amount of motivation or example code, so you may wish to check some of the tests:
http://cpansearch.perl.org/src/CYCLES/Test-Magpie-0.05/t/mockito_tutorial.t
http://cpansearch.perl.org/src/CYCLES/Test-Magpie-0.05/t/basic.t
I'm making an attempt at setting boost's unit test framework up for myself, but due to having to use C++98, I also have to use boost 1.45. Due to this, I find I can't make use of datasets the way I'd like (have test cases that have an arity of 2 and a dataset of pairs (input_val,expected_val)). It's looking like I'll be able to get an approximation going using a global fixture (The fixtures would have to be global if I want to not have it reset every test case. This issue is documented in another post), but I dislike the idea of throwing all that into global. Does anybody know a better, possibly more elegant solution?
# provided the info I needed. If anybody else is looking for a good unit testing framework for C++98, Catch seems great so far!
I am using StoryQ to perform some basic integration testing and we are using NHibernate as our ORM.
When I started, I didn't know that NHibernate implemented the Repository pattern and so I created my own IRepository in order to run my integration tests.
However, considering that NHibernate already implements the Repository pattern, I assume that it is doing so against some kind of interface. So, I would like to work against NHibernate's interface for the Repository if my assumptions are correct.
I have tried to search for it but I come across information that to do that I need to work against the ISession interface. As I do not really know NHibernate that well, can someone explain why I would need to implement my fake repository against the ISession interface? What is the IRepository equivalent in NHibernate? Is there some tutorial which goes into greater depth into the matter?
NHibernate doesn't implement the Repository pattern. It replaces it.
SQLite in-memory databases are nice if you've got a simple database implementation, but I've found that things can become cumbersome quickly, almost to a point where it becomes as painful, if not more, to use SQLite as it is to stub/mock ISession/ICriteria/etc.
One perfect example of this: In one of my recent projects, in which I was using PostgreSQL as my production database and SQLite as my test database, I had a need to extend NHibernate to add support for an aggregate function that was recently added to PostgreSQL. Figuring out how to add this was a story in itself, but I worked it out. I then had to find a functional equivalent in SQLite. I needed an aggregate function that worked in the same exact way as its Postgres counterpart. There was none. I asked around and was told that there were ways to extend NHibernate to "fake" this function in SQLite. I also had the option of extending SQLite to add this functionality.
All I wanted to do was write two, maybe three, tests around the scenario that I was trying to implement. I ended up spending way too much time trying to ensure functional equivalency between the two systems. It wasn't worth all this effort for one function. And what would happen if down the road, I needed to add another function?
I think SQLite is useful. It's a great lightweight database system and I love that you can conveniently use it as a in-memory database for simple scenarios. However, I'm not sure it's worth using beyond that. I think from now on, I'll be using the same database across all environments, even if it means having slower integration tests for all data persistence logic.
I'm not sure where in core NHibernate there is an IRepository interface (AFAIK there's none) so you might be referring some other NHibernate side projects.
It is not the best approach to go about mocking ISession either. The best thing in my opinion, is to use a real in-memory database that is fully supported by NHibernate. You may need to check how to configure NHibernate to run on sqlite in-memory database, which basically is just configuring NHibernate in your tests.
The good thing about this approach, is that tests run with a very good speed, as if there's no database involved, and you don't need to abstract away all your ORM functionality (and loose features too) just to run / drive your tests.
The approach I've taken is to implement an IRepository and GenericRepository, to wrap the ISession Save and Delete methods. Also, GenericRepository also implements IQueryable using NHibernate's LINQ provider. My implementation borrows heavily from Javier Lozano's MVC Trubine project. His implementation is here: https://github.com/jglozano/mvcturbine/blob/master/src/Blades/NHibernate/MvcTurbine.NHibernate/GenericRepository.cs
This works for about 80% of the queries I need. For the rest, I create a Query Object to wrap the query. That way, I can use ICriteria, IQuery, IQueryOver or LINQ, whichever the needs of the query dictate. Fabio Maulo explains it pretty well here: http://fabiomaulo.blogspot.com/2010/07/enhanced-query-object.html
Both approaches allow easily mocking away the dependency.
I'm creating a design document for a security subsystem, to be written in C++. I've created a class diagram and sequence diagrams for the major use cases. I've also specified the public attributes, associations and methods for each of the classes. But, I haven't drilled the method definitions down to the C++ level yet. Since I'm new to C++ , as is the other developer, I wonder if it might not make sense go ahead and specify to this level. Thoughts?
edit: Wow - completely against, unanimous. I was thinking about, for example, the whole business about specifying const vs. non-const, passing references, handling default constructor and assigns, and so forth. I do believe it's been quite helpful to spec this out to this level of detail so far. I definitely have gotten a clearer idea of how the system will work. Maybe if I just do a few methods, as an example, before diving into the code?
I wouldn't recommend going to this level, but then again you've already gone past where I would go in a design specification. My personal feeling is that putting a lot of effort into detailed design up-front is going to be wasted as you find out in developing code that your guesses as to how the code will work are wrong. I would stick with a high-level design and think about using TDD (test driven development) to guide the low-level design and implementation.
I would say it makes no sense at all, and that you have gone too far already. If you are new to C++ you are in no position to write a detailed design document for a C++ project. I would recommend you try to implement what you already have in C++, learn by the inevitable mistakes (like public attributes) and then go back and revise it.
Since you're new, it probably makes sense not to drill down.
Reason: You're still figuring out the language and how things are best structured. That means you'll make mistakes initially and you'll want to correct them without constantly updating the documentation.
It really depends on who the design document is targeted at. If it's for a boss who is non-technical, then you are good with what you have.
If it's for yourself, then you are using the tool to help you, so you decide. I create method level design docs when I am creating a project, but it's at a high level so I can figure out what the features of the various classes should be. I've found that across languages, the primary functionalities of a class have little to do with the programming language we are working in. Some of the internal details and functions required certainly vary due to the chosen language, but those are implementation details that I don't bother with during the design phase.
It certainly helps me to know that for instance an authorization class might have an authenticate function that takes a User object as a parameter. I don't really care during design that I might need an internal string md5 function wrapper to accomplish some specific goal. I find out about that while coding.
The goal of initial design is to get organized so you can make progress with clarity and forethought rather than tearing out and reimplementing the same function 4 times because you forgot some scenario due to not planning.
EDIT: I work in PHP a lot, and I actually use PhpDoc to do some of the design docs, by simply writing the method signature with no implementation, then putting a detailed description of what the method should do in the method header comments. This helps anyone that is using my class in the future, because the design IS the documentation. I can also change the documentation if I do need to make some alterations while coding.
I work in php4 a lot, so I don't get to use interfaces. In php5, I create the interface, then implement it elsewhere.
The best way to specify how the code should actually fit together is in code. The design document is for other things that are not easily expressed in code. You should use it for describing the actual need the program fills, How it interacts with users, what the constraints are in terms of hardware and operating systems. Certainly describe the overall architecture of your application in a design document, but, for instance, the API should actually be described in the code that exposes the API.
You have already gone far enough with the documentation part. As you still a beginner in C++, when you would understand the language, you might want to change the structure of your program. Then you would have to do changes in the documentation. I would suggest that you have already gone too far with the documentation. No need to drill more into it
Like everyone else says, you've gone way past where you need to go with the design. Do you have a good set of requirements to the simple true/false statement level that you derived that design from? You can design all day long, but if you don't have requirements that simply say WHAT you're going to do, it doesn't matter how good your design is.
Our application exposes queries by way of web services, and what we've found is that our clients often want custom queries, either by way of further limiting the results returned by specifying additional criteria, or by asking for things that we don't already expose.
Now, we can take the approach of creating new methods for each of these new methods, but that's somewhat inconvenient; deployment of our application at a client site usually requires weeks of staged integration testing. We've proposed a named query mechanism, where the application administrator would define queries by name that are parameterized, and a corresponding web service that simply invokes these parameters. However, I can't help but think that someone has solved this problem before, so I'd like some input from the SO community on possible designs.
Thanks!
Updates
The specification pattern is a good one, but our application deals with enough data that we want to push as much of the querying work down into an RDBMS, which can do a better job of optimizing the query plan than we would ever want to. Moreover, we support three RDBMS backends, so we're stuck using a greatest-common-denominator approach: we use as much capability as the least functional database can provide.
I would also recommend to consider the "Specification Pattern" in this type of applications as a design decision for your backend. Check the following posts about "Specification Pattern":
http://www.mattberther.com/2005/03/25/the-specification-pattern-a-primer/
http://devlicio.us/blogs/jeff_perrin/archive/2006/12/13/the-specification-pattern.aspx
Take a look at Hibernates Criteria API and use it or build some similar
functionality for Your users.
If it's worth the effort, provide a tree-like interface for grouping criterias. ("all criteria of a group must match" / "one criteria must match" / "negate")
Advantages:
Easy to build.
User parameters are possible.
Powerful queries are possible.
You can apply restrictions like SELECT ... FROM table WHERE someRestriction AND (user-provided criteria)
Since we really don't know which how your users use your interface it seems a little premature to give a technical advice on something that feels a lot closer to "Inmates are running the Asylum" problem.
There are some very good advice and common ways to solve this i technical aspects but do they work for your users? Maybe the really don't give a crap about your problem but rather have a fine working one button solution? (Or more like google?)