Class UserService question

OpenEMR Development
1 
public function getCurrentlyLoggedInUser()
{
    return $this->repository->getCurrentlyLoggedInUser();
}

We may save the trip to the namespace repositories changing the code a bit, like this

public function getCurrentlyLoggedInUser()
{
    return  $_SESSION['authUser'];
}

Any Thought

2

The getCurrentlyLoggedInUser function actually returns a result from the database, not just the userid from the session, so this wouldn’t work.

Also, a cool feature in the new forums is markdown is fully supported. If you wrap your code blocks with three back ticks on you will notice you get syntax hylighting on your code, I edited your original post, if you go into edit mode you can see exactly how to set it up :slight_smile:

1 Like
3

Hi Robert, Thanks for new forum you gave it to the community, I like it

I took a look of the UserRepository.php and the getCurrentlyLoggedInUser() gets the userId from session.

@MatthewVita

Roberto

4

You are right that we use the $_SESSION value in there, but that method actually returns an instance of User not just a string representing the ID of the user

5

Thanks Robert

Doctrine is clear as dishwater.

1 Like
6

Yeah, I’ve spent many, many, many hours buried in the doctrine docs to grasp it. And I’m still pretty shaky with it

7

The OpenEmr modernization project has a steep learning curve

8

Some aspects certainly do. We’ve been working hard to get some basics done so other debts can see working examples, but we can always try to provide more.

Unfortunately it seems to be a side effect of reorganizing legacy code.

9

There is no doubt we need orm rescue. The transition from legacy to php orm is the challenge.

10

Hi @robertovasquez and @robert.down, thanks for the honest feedback.

I come from the enterprise world where ORMs are the way of the land. However, I realize the learning curve is pretty high.

As you may know, other OpenEMR projects have taken my attention as of late, but when I return to the backend modernization work, I believe organizing all of the SQL queries in domain-partitioned service layers (not using anything fancy) may be the better approach. I actually did this with the recent FacilityService openemr/FacilityService.php at master · openemr/openemr · GitHub and I think it’s pretty elegant. As a step further, a lightweight query builder may be nice to use too, but that’s mainly for syntatic sugar.

Interesting in your thoughts.

cc: @brady.miller

-m

11

Hi @MatthewVita @robert.down
I did not find the Facility class in entities.
If Doctrine ORM will be the way of the land in OpenEMR. It will be better to get my hands dirty.

12

Roberto,

The Facility class is a service class that is NOT using Doctrine. The point I was making that it’s pretty simple without the ORM and appears to be elegant so we may skip out on ORMs because of the learning curve (not for you, because you’ll be able to pick up on it quickly but other contributors may not be up to date on more advanced patterns such as ORM)

-m

13

I understand, The controller class C_Document will take care of the DB layer.

HUMM,

OO code not using Doctrine.
PRO:
Same elegant front-end
Ease to develop and maintain front-end
Ease to develop and maintain back-end

More Pro that Con, But

I am missing Security. Which methodology will be more secure to prevent Sql Injection?

14

Ideally, the controller just calls out to the relevant services.

Yes.

Both solutions can prevent injections. Good question though.

15

Hi Matthew
Can we call this sub project “OpenEMR ORM” ?

1 Like
16

Hi @robertovasquez,

Thank you so much for putting thought into this. I believe there is a better path than the one that I started us down.

If it’s okay I’m going to just respond to your email asking how to get started in the backend modernization project here.

Basically, there are MANY things that need to be cleaned up in the codebase to follow a proper MVC style codebase. I would say that where you can start is by removing all of the SQL queries in the views and putting them in centralized services. For instance, I recently removed about 100 (mostly copy/pasted) SQL queries in the views surrounding “Facilities” and I put them into a “FacilityService” that the views call out to. This is not only good from a code quality perspective, but it will help us in the future because the UI and the business logic are not tangled together (will help with making a REST API or a FHIR API).

The current services use Doctrine (except for the FacilityService, which is straight SQL). It appears that Doctrine may have too high of a learning curve for the greater community and we may want to just stick with straight SQL.

With this said, here are some tasks you can jump on:

  1. look into building services with straight SQL or something like GitHub - nilportugues/php-sql-query-builder: An elegant lightweight and efficient SQL Query Builder with fluid interface SQL syntax supporting bindings and complicated query generation.
  2. Study all “Drugs” related tables and create a DrugService that the views/controllers call out to

-m