Organizing service of BusinessLayer

Question

currently trying to think of a strategy for implementing services in the business layer. My first approach was to implement a service functionality per class, but the number of functionalities will eventually grow and become hard to call from presentation layer since id have to remember them all (Large amounts of classes). The opposite alternative would be to have one single class with all services implemented which would created a gigantic file.

I've seen implementations that implement functionalities(methods) inside each a class such has (ProductBLL ou CompanyBLL) which would make the services more manageable, however some services such as "getmeProductsAndCompanies" which are somewhat frequent doesn't seem to belong neither to ProductBLL nor CompanyBLL.

My question is: Is it good idea to make a class AplicationService that has a method per Service that instantiates the correct ServiceClass and correct method? My goal with this was to instantiate in PL AplicationService as and as.getmeProductsAndCompanies()

The internet material i passed through so far has very theoretical or very complex solutions. I am open to suggestions too.

score 0 · Answer 1 · answered Mar 26 '15 at 04:10

0

Use composite pattern. Basically, you create as many small classes / functions as you can. Then those parts will be called by bigger class/function. Then the bigger class can also be used by some more bigger class again.

answered Mar 26 '15 at 04:10

Fendy

4,565
1
20
25

I think you are thinking in same way as FractalizeR only didn't accept your answer because to my believe composite pattern focus on making an object A that derive to B and C, and then say that C can also be a A, thus the common use of shapes example. – Digy Mar 26 '15 at 13:32

score 0 · Accepted Answer · answered Mar 26 '15 at 07:45

My first approach was to implement a service functionality per class, but the number of functionalities will eventually grow and become hard to call from presentation layer since id have to remember them all (Large amounts of classes)

I do not think aggregating all services into a single facade will help matters. It will only complicate them. Consider instead structuring services and devising some naming pattern for them.

For example, you have OrderService that does everything to orders (bad name choice, btw ;) ). Eventually it grows too big, and when this happens, you must split it in two. When splitting, you must use functional approach to naming. The name of the service must answer the question "What does this service do exactly and with what types of data". For example, OrderDisplayService looks like a good choice to me.

When you must find out which service you need to inject into your governor entity (MVC-like controller, usually), you must first type service namespace name (\Acme\Services\), then the object name you want to deal with (Order), then type a verb, describing what exactly you want to do with it (Display) and then press your IDE autocomplete buttons. You will have a relatively short list of services, available for injection (I suppose you use some IoC container for that).

Split your services into layers or units so that when you work in IDE, you could see only a functionally complete part of them in the currently expanded directory

Organizing service of BusinessLayer

2 Answers2