Tag Info

New answers tagged

5

Does it mean that if we are using an ORM tool we do not need to design our database like before? You still need a design; it just takes a somewhat different form. The nature of the design shouldn't change all that much; you're still going to have records and relations, they'll just look a bit different. Does it mean that we do not even have to come ...


0

Not sure if this answers your question appropriately, but I would advise against using EF or Nhibernate or any other large ORM for non classic DB structures. I highly suggest using a microORM such as Dapper, petaPOCO, or Susanoo (full discretion Susanoo is my open source project). EF for instance has some pretty stringent rules and conventions that don't ...


1

Does this pattern have a formal definition? This is also referred as convention over configuration. Who invented it? This is a hard question, according to Wikipedia it goes back to 1960's. Apparently it's influenced by the concept of default. Is it considered a DSL? I would say yes, because it's specific to the domain of ORM framework (related to the ...


0

We can solve any problem by introducing an extra level of indirection. I doubt that adding another level of abstraction would solve your problem. I think the question you should be asking is 'do I need two repositories for this or just one' and the answer to this depends on a lot more than can be found here... No harm in starting off with the one Dog ...


0

You could try using lazy loading of the related objects (Companies, Division, etc.). In your business layer, retrieve the related objects only if you require them. By default they will be null and save you heap space. If lazy loading becomes too complex (it usually does because of even more annotations and configurations), you can use indirect references. ...


1

My approach is: prefare unidirectional relations (eg. when loading role, you don't usually need everyone with that role, and if you need it for user management, you can quary for it) prefare lazy loading, so you don't manipulate huge graphs by accident if you don't need entity as result of query, return non entity object (via select new). JPA is not ...


1

Both options have drawbacks: the first depends on the "magic string" of the column name, the second depends on the "magic number" of the column index. A good suite of automated unittests could cover either usage and help a great deal in preventing breaking changes though... I would personally favor the first for a number of reasons, but they are probably ...


3

The connecting table that you speak of is called a junction table. Using the Wikipedia example, they have 3 tables defined. User ---- User ID User Login User Password User Name Permission ---------- Permission ID Permission Description UserPermission -------------- User ID Permission ID Now, you can map these 3 tables to PHP classes. It would probably ...



Top 50 recent answers are included