1

I have few models, which I've been implementing for a while in every sandbox project and it got me thinking. What is the difference between few models with constant implementation Vs. my own lib, which would in theory contain same files.

Question #1 : Is there any difference in exec time & page loading between few model objects and same objects from library?

Question #2 : Why should I use library instead of few models (or vice versa)?

Question #3 : If there isn't any difference in this two, should I create my own lib just for easier composer implementation OR some sort of custom-sandbox git rep with models is better option?

Vladimir
  • 388
  • 1
  • 13
  • What do you mean by "models"? – Tomas Votruba Aug 19 '16 at 16:52
  • Classes, NetteObjects, for example I have Log model which is implemented in basePresenter and Logs anything I need to log. Or I have Object that extends Nette/Object and is basically parent of other classes in my App/Model. It contains set of useful functions and checking methods. Next, example from last app, I've built calendar, which contained a lot of different date/time related functions and also was used to create data structure for front end. – Vladimir Aug 19 '16 at 20:52
  • I see. Some minimal code might be helpful: what do you want to load from where? – Tomas Votruba Aug 19 '16 at 22:15

2 Answers2

2
  1. It isn't or is negligible. Your classes always have to be included. It doesn't matter if they are included by composer autoload or nette RobotLoader.
  2. If particular functionality can help other people, you can help someone a lot by creating a library. If it is too specific for your app, go with libs dir or something directly in app, you can change functonality more easily later if needed.
  3. I would say both. Creating and maintaining sandbox is much easier than lib shared by many projects. With lib, you need to keep backward compatibility for example. Also, if you have many non-related classes, it doesn't make much sense creating one library from them. Reather create more libraries implementing specific functionality. For example, logging class which will include your LogModel. But before you start, try search packagist if there already isn't lib you need. For logging, Monolog can be usefull. Your calendar class is great candidate for library.
Tomáš Jacík
  • 645
  • 4
  • 12
  • Ahh, now I get it! So, basically, main questions are whether it's custom for certain app AND whether classes are related. For example if I go for some sort of CMS, it should be lib, but if we're talknig about something like, let's say, some sort of database migration tool, which I'm plannigto use as part of CMS, but sometimes as independent module for other apps, I should keep it as class rather than go for lib for this particular feature. Correct? – Vladimir Aug 20 '16 at 11:01
  • In my opinion, CMS is too complex to be lib. On the other hand, it's goot idea to have more libs with specific functonality like db class, pager, etc from which CMS will consist. Of course, you can publish your CMS app on github to offer it to other people too. Database migration tool is great example for lib, installed with composer, because you can share it with other apps. There shouldn't be much functionality wchich is specific to one app. But for example UserModel, regardless it is used same way in all your apps isn't good choice for lib. Hope you understand. – Tomáš Jacík Aug 21 '16 at 14:15
1

Even if I don't understand your situation completely, I'll try to answer as best as possible:

1) not really, it's class autoloading, no matter where it is located

2) I recommend moving code to library when you find that some classes have common meaning, that could be abstracted to some directory, for e.g.

  • FileManager
  • ImageResizer
  • ACL
  • CMS
  • ...

3) If your code is stable and consistent (= doesn't change in app), I'd go for package. If you have to customize it, I'd keep it specific for every app.

This all depends on your specific classes. The best would be to see whole project and problems you have.

Tomas Votruba
  • 23,240
  • 9
  • 79
  • 115