On 8/5/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-08-04 at 17:05 -0700, Michael Jouravlev wrote:
> > You mean, separate view from the business object, not from the data?
> > ;-) Anyway, I am not sure that this separation is needed, unless view
> > layer is developed by an evil third party contractor.
>
> I give you a RL example. We have a relative large portal here, with some
> 10.000 classes and thousands of requests pro second, with large
> databases in the back etc.
> Our development environment contains at least 3 server for each test
> cycle (unstable, stable-develop, integration, test). So it's about 12
> machines you need as developer. Still I like to work at home from time
> to time. I can't afford having 12 high-end machines at home. Instead we
> have alternative implementations for all persistence layers, which go to
> inmemory dbs or filesystems instead of real dbs. The business layer is
> the same. We only switch the persistence layer and as by magic, it all
> runs on my notebook. If my business object would encapsulate this
> knowledge, i wouldn't be able to do this. But as we are
> component-oriented we switch complete components.
I did not argue with above...
> It wouldn't be possible without DTOs.
...but this is I am not sure about. You explained DAO, not DTO.
> As for the Serializable -> you know something slower then that? I don't.
> If you are playing around, you can distribute with serializable and RMI,
> sure thing. If you need performance - forget it.
I will not argue with that, frankly I did not do tests myself.
> Example:
> private String mail;
> public String getMail(){
> return mail;
> }
>
> public void setMail(String aMail){
> mail = aMail;
> }
>
> why is that uglier then direct property access?
The above syntax already pretty ugly, but do not forget the comments
for the field, for getter and for setter. Of course you can write:
private String mail;
public String getMail() {return mail;}
public void setMail(String aMail) {mail = aMail;}
which still does not look beautiful, but at least relatively compact.
If I could write one comment above this group, like "this is mail
property, use legitimate [EMAIL PROTECTED] syntax" and it would apply to this
group like to a property, that would be ok. But javadoc does not know
properties, it lists methods and fields, which is too much for simple
cases like this.
On 8/5/05, Larry Meadors <[EMAIL PROTECTED]> wrote:
> Now, instead of:
>
> someValue = foo.getMyProperty();
> foo.setMyProperty(someValue);
>
> ...I can do this instead:
>
> someValue = foo.MyProperty;
> foo.MyProperty = someValue;
Exactly. Do not forget, that C# was created by the guy who created Delphi ;)
On 8/5/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> I would personally tend to agree the C# syntax is cleaner... but I don't
> think the difference is all that big frankly and it probably comes down to
> a matter of developer proference rather than what's actually "better" in
> some way.
You can use Object Pascal / C# property as rvalue or lvalue. You can
define property to point to actual private field directly, and then
refactor it, using methods. Notice that client would not know about
it! In Java you have to use either getter or setter, and refactoring
from using field directly to using getters is a pain since it affects
clients of your object. Java properties suck. I don't even mention
that there is no *simple* way to create Java property accessible from
IDE.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
