Zend_Bo is an aggregator of simple business object classes. Very often we need to manipulate with primitive data objects, which are similar in almost all web applications, like date, name, password, email, price, IP address, IBAN bank account, SWIFT code, phone number, etc. There are many business areas where many types of such business objects could be used. The proposed set of Zend_Bo components will provide certain standardization and unification for the operations with said business objects.
We already have Zend_Date, Zend_Currency and some other good classes. But real life web applications need more classes, that will automate routine manipulations with business objects.
the idea looks great, but user cases make it somewhat confusing
at first, it looks like data container (value object of DDD comes to mind, so Zend_ValueObject name makes more sense to me),
but then I see service layers behind and object behaviour becomes unclear
for example:
first you create an IP object with hostname (btw what about IPv4 vs IPv6 ?), then you access it's country property
but where did that data come from is not clean? I assume some geoip service layer behind
same with Zend_Bo_Money, it assumes that some currency conversion layer is already in place,
in prototype is see it as a simple _getRate method, but what if I wish to use some conversion API, or currency rates from local DB
so to me it looks good as a data container, because there are many things you can present as a standard container,
but service layer raises a lot of questions like: DI, service interface class etc
Denis, thanks for your comments. You're right, every business object (BO) will have its own implementation and its own subsidiary layers, which will be responsible for data manipulation. I didn't specify them in the skeleton, since the proposal is about Zend_Bo component at first. Once it's approved, every BO will be discussed individually. This was my plan. For example:
Zend_Bo_Money will implement:
rates conversion by different converters, like xe.com, oanda.com, etc.
using pre-defined rates, from DB, files, INI, etc.
caching of conversion requests, with Zend_Cache
configuration of precision (cents, 1/100 cents, 1/10000 cents, etc)
Zend_Bo_Ip will implement:
getting location information, with geoIP, or other provider
IPv4, IPv6 with one unified interface
validation of IP address/port (ping, port check, etc.)
getting metrics of the address (traceroute, ping, etc)
Not all applications need these functions, but this is the benefit of Zend_Bo component - you get a simple business object with a very powerful functionality behind. Now, as I understand, the point is to approve the entire idea of Zend_Bo, and then continue with discussions on specific business objects.
3 Comments
comments.show.hideFeb 21, 2010
Denis Portnov
the idea looks great, but user cases make it somewhat confusing
at first, it looks like data container (value object of DDD comes to mind, so Zend_ValueObject name makes more sense to me),
but then I see service layers behind and object behaviour becomes unclear
for example:
first you create an IP object with hostname (btw what about IPv4 vs IPv6 ?), then you access it's country property
but where did that data come from is not clean? I assume some geoip service layer behind
same with Zend_Bo_Money, it assumes that some currency conversion layer is already in place,
in prototype is see it as a simple _getRate method, but what if I wish to use some conversion API, or currency rates from local DB
so to me it looks good as a data container, because there are many things you can present as a standard container,
but service layer raises a lot of questions like: DI, service interface class etc
sorry for a long comment
Feb 21, 2010
Yegor Bugayenko
Denis, thanks for your comments. You're right, every business object (BO) will have its own implementation and its own subsidiary layers, which will be responsible for data manipulation. I didn't specify them in the skeleton, since the proposal is about Zend_Bo component at first. Once it's approved, every BO will be discussed individually. This was my plan. For example:
Zend_Bo_Money will implement:
Zend_Bo_Ip will implement:
Not all applications need these functions, but this is the benefit of Zend_Bo component - you get a simple business object with a very powerful functionality behind. Now, as I understand, the point is to approve the entire idea of Zend_Bo, and then continue with discussions on specific business objects.
Feb 07, 2011
Dolf Schimmel (Freeaqingme)
Archiving this proposal, feel free to recover it when you want to work on it again. For more details see this email.