>businessobject.save() > >It is better to extract the persistence aspect from the business objects (think of Aspect >oriented programming here) and put it in a separate layer away from your business >objects. You call persistence through a manager: > >PersistenceManager.Save(businessobject)
with the second option however, you lose the ability to override any of the persistent methods for a given object.
::with the second option however, you lose the ability to override any of the persistent ::methods for a given object. No, not necessarily. THe manager could call into the object. This is about responsibility to the USER, not about internal stuff :-) Anyhow,
as I said: the second method is faulty, too. Hardly better than the first one.
I've read the docs of EntityBroker 3, looking forword to check EntityBroker 4. As far as I've read it seams the approach seams interesting and effective. There some nuinsances though: 1) The main nuisance might be the need to declare all persistance classes
abstract. This is a clever approach from one said, but also may be an inconvienience. For instance object instantiation is no longer possible to be done with "new" but with a factory; (Flexibility). 2) The use of properties is already locked for persistance
purposes unless I missed something from the Docs. That is, properties can no longer be used to enforce business rules apart from persistance. Access to attributes need to be done always through Properties, even internally. (Flexibility) 3) The mapping is done
in the class itself, using Attributes. This leads to recompiling the code every time the mapping changes for some reason. (Flexibility) 4) Code generation, might be a nuisance (for debuging and compilation actions), it depends how well it integrates with Visual
Studio. As I've said this can be nuisances but thy need to be put within a perspective that encompasses the benefits themselfs: 1) No need for post compile actions (post compile byte code modification) (Flexibility); 2) No need to inherit from a base persistance
class (Flexibility); 3) Reflection is minimized greatly (Performance); 4) No need for dynamic proxies generation (Performance); 5) No need for dynamic message interseption (Performance). Al in all a clever/good solution as far as I've read the docs. Nuno
> This is about responsibility to the USER, not about internal stuff and to a user, calling myobject.save() is very convenient and logical. of course, myobject.save delegates the work to mymanager.save
Let me just answer to this: ::1) The main nuisance might be the need to declare all persistance classes abstract. This is ::a clever approach from one said, but also may be an inconvienience. For instance object ::instantiation is no longer possible to be done
with "new" but with a factory; (Flexibility). Done in 2004. Go and download it, then look at the sample. ::2) The use of properties is already locked for persistance purposes unless I missed ::something from the Docs. That is, properties can no longer be used
to enforce business ::rules apart from persistance. Access to attributes need to be done always through ::Properties, even internally. (Flexibility) Done in 2004 :-) The persisted properties are declared in a generated base class, and can be overwritten to
put business logic in. The 2003 pattern of using "protected properties" WAS a little tendious, agreed. ::3) The mapping is done in the class itself, using Attributes. This leads to recompiling the ::code every time the mapping changes for some reason. (Flexibility)
By design - this is one of the flexible items that noone REALLY cares about, and the benefits are significant. Noone runs around and just changes table names. Have a realistic look at it, please. Actually we go gurther with 2004 (beta 2), generating the database
(with a tool) based on information in the assembly. We consider adding an "overlading mechanism" using an XML file :-) ::4) Code generation, might be a nuisance (for debuging and compilation actions), it depends ::how well it integrates with Visual Studio.
It integrates VERY well :-) Right mouse click on the schema file, click regenerate code and you are done. This is for EntityBroker 2004 - 2003 does not require any generation step. How do you think we do code generation? 2003 does bytecode generation on a
level you will rarely see. ::As I've said this can be nuisances but thy need to be put within a perspective that ::encompasses the benefits themselfs: ::1) No need for post compile actions (post compile byte code modification) (Flexibility); We do NOT make
post compile modifcaions in 2003. The modifications are done at startup time, not by modification but by class generation of classes that never hit the hard disc. How do you come to the conclusion that we do post compile actions? ::2) No need to inherit from
a base persistance class (Flexibility); Which - sorry - is garbage. I have not seen one case (in 8 years I work with O/R mappers) where I required or saw a base class being used. I have met a lot of people which said this is inflexible, and all have failed
to come up with a sample where this was really limiting. OTOH, there is a lot we do automatically, like integrating databinding, which is very tendious to do - so tendious that EntityBroker 2004 has (in the foundation) a class named SmartObject that is an"EntityObject
without persistence", just because it is so convenient to use. Have a look at the interface EntityObject exposes and then tell me (realistically) whether you think you know how to implement them all :-) ::3) Reflection is minimized greatly (Performance); Non-issue.
We do not use any reflection API at runtime. The attributes are only evaluated when you create the EntityServer (onc at application start) and never again. We work with an internal schema graph that is speed optimised and that is compiled from the attributes
of all availabel classes. ::4) No need for dynamic proxies generation (Performance); Sort of. We do not need them. They are in by design - EntityBroker 2004 will be the most flexible system regarding remoting that you have seen in beta 2 - and for this we
NEED context bound objects. The perforamnce hit is not significant without remoting, but with remoting we will rely heavily on custom written dynamic proxies. ::5) No need for dynamic message interseption (Performance). We do not do it :-) NOW. We will do
it (in remoting scenarios) to gain performance. How do you come to the conclusion we do message interception? Read the documentation fully, before making assumptions :-)
thona, I have looked at the download area on you're site./ but there is now entityBroker 2004. just the 2003 one :( did you place it at a 'hidden' area? ;)
Bluemagics Weblog: "I'll always make your dark sky blue!"
Actually no, it is on the public downloa area:
http://www.thona-consulting.com/content/forms/download.aspx the last one: EntityBroker2004Preview Last updated: 10/7/2003 4760 kB 2004.0.0.40a It is not working totally correct, though - some bugs have crept int. We reschedule this right now and will release
2004.0.0.41 today as another build. Changes are: * Some bugs fixed - we had some stupid issues that crept into .40 * Different visual controls - we incorporated an update from our controls provider, from Infragistics 2003 vol 2 to 2003 vol 3 - nothing change
visible, though. * Starter documentation, with a pretty good overview of the different architecture schools and a first steps guide. No images yet, though :-) Look for this one a little later today.
::in EB2k4 (or any version for that matter), can you change the stub class without having to ::recompile the inherited class? No, what sense would it make? I mean, they are both in the same project. The only reason to change the stub is when fields are added
or deleted. In this case a recompile is necessary anyway. What problem do you try to solve?
m7
Contributor
4225 Points
843 Posts
Re: Evaluation of the Microsoft's way of (3-Tier) architecture
Oct 08, 2003 07:47 AM|LINK
thona
Member
20 Points
2923 Posts
Re: Evaluation of the Microsoft's way of (3-Tier) architecture
Oct 08, 2003 08:22 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Evaluation of the Microsoft's way of (3-Tier) architecture
Oct 08, 2003 09:19 AM|LINK
m7
Contributor
4225 Points
843 Posts
Re: Evaluation of the Microsoft's way of (3-Tier) architecture
Oct 08, 2003 10:45 AM|LINK
thona
Member
20 Points
2923 Posts
Re: Evaluation of the Microsoft's way of (3-Tier) architecture
Oct 08, 2003 11:18 AM|LINK
Bluemagics
Participant
1955 Points
391 Posts
Re: Evaluation of the Microsoft's way of (3-Tier) architecture
Oct 08, 2003 12:58 PM|LINK
Bluemagics
Participant
1955 Points
391 Posts
Re: Evaluation of the Microsoft's way of (3-Tier) architecture
Oct 08, 2003 01:00 PM|LINK
thona
Member
20 Points
2923 Posts
Re: Evaluation of the Microsoft's way of (3-Tier) architecture
Oct 08, 2003 01:09 PM|LINK
Stephen Vaki...
Contributor
2540 Points
508 Posts
Re: Evaluation of the Microsoft's way of (3-Tier) architecture
Oct 08, 2003 01:15 PM|LINK
thona
Member
20 Points
2923 Posts
Re: Evaluation of the Microsoft's way of (3-Tier) architecture
Oct 08, 2003 02:49 PM|LINK