Welcome Guest, Not a member yet? Register   Sign In
Poll: Add the possibility of using a Service Layer?
You do not have permission to vote in this poll.
9 52.94%
4 23.53%
4 23.53%
Total 17 vote(s) 100%
* You voted for this item. [Show Results]

Add the possibility of using a Service Layer

Hi all,

In thread http://forum.codeigniter.com/thread-1651.html I proposed to use a service layer. Experienced developers know the advantage of a service layer and so it would be nice if it could be used in CodeIgniter. To be very clear: I do not suggest you HAVE TO use it, but you CAN use it if you want.

Anybody who does not know what a service layer is, please read some articles on the internet about "service layers". Sometimes they are also called "Application Layer" (or wrongly "Business Logic Layer") .

After reading, things you must understand:

- A service layer is a thin layer between your controller and your model(s).

- A service layer has nothing to do with a web service.

- "A service layer can be used as an interface for different clients." This is Enterprise Architecture Software stuff. That is not what we are talking about.

- A service layer does not contain the business logic. The business logic stays in the models (where it belongs).
See http://www.martinfowler.com/bliki/Anemic...Model.html (read the part at the end about "Application Layer")

- If you do not need it, do not use it!
See http://codeutopia.net/blog/2011/05/22/yo...s-are-okay (read the WHOLE article and the comments)
or http://programmers.stackexchange.com/que...519#162519 (read the answers)

What are the advantages?

- separation of concerns;
- encapsulation of the application's business logic;
- the controller is kept thin;
- better testable (dependencies are abstracted away and you can mock the methods in the layer)

What are the disadvantages?

- possible over engineering (but again: when you do not need it, do not use it)

It is possible to create a service layer in CodeIgniter 3 (as you can see in my example in thread http://forum.codeigniter.com/thread-1651.html), but not the way it should be done. It should be part of the framework.In this way you can create a service (MyService) by extending core class "Service", which should be part of 'system', the same way you extend "Model" and "Controller". The service layer just adds an extra level of abstraction. On itself it doesn't do anything. Adding it to the CodeIgniter framework is easy. It is a small change with little impact.

Note: If you have never used a service layer (application layer), you might think: "He I like CodeIgniter because it is simple and I do not need this.".
You are right, you can do without it, but after using it, you probably understand why it is very useful indeed. So in doubt, please vote 'maybe'.

So what do you think?

A service layer can contain the business logic.

(This post was last modified: 04-13-2015, 03:58 AM by RWCH.)

(04-12-2015, 07:37 PM)cjj Wrote: A service layer can contain the business logic.

You are right. It definitely can ... and to be honest I like to use it for business logic. That is what we also do at my office and I have not found any downsides.

But after reading Martin Fowler's article (http://www.martinfowler.com/bliki/Anemic...Model.html, the part at the end about "Application Layer"), I realized that (at least most of) the business logic should be in your models.  

I think this separation is not as clear as between the other layers, and it is not really wrong... so what keeps us from doing it Wink

(04-12-2015, 02:37 PM)PoEAA: Wrote: A common approach in handling domain logic is to split the domain layer in two. A Service Layer (133) is placed over an underlying Domain Model (116) or Table Module (125). Usually you only get this with a Domain Model (116) or Table Module (125) since a domain layer that uses only Transaction Script (110) isn't complex enough to warrant a separate layer. The presentation logic interacts with the domain purely through the Service Layer (133), which acts as an API for the application.

As well as providing a clear API, the Service Layer (133) is also a good spot to place such things as transaction control and security. This gives you a simple model of taking each method in the Service Layer (133) and describing its transactional and security characteristics. A separate properties file is a common choice for this, but .NET's attributes provide a nice way of doing it directly in the code.

PoEAA then goes on to define a range of Service Layers from a minimal facade layer to a layer which encapsulates most of the business logic for an application, with the latter usually implemented over a Domain Model with an Active Record data source layer. In the middle somewhere is a controller-entity style sometimes implemented in HMVC.

I think it's an interesting idea for an addition to CI, but I'm not sure how popular it could become without some significant improvements in CI's Domain and Data Access layers, especially since it has a wide range of valid use cases and can be easily implemented without specific support from the framework.

Great piece of information guys. Keep up the good work.

Theme © iAndrew 2016 - Forum software by © MyBB