471,596 Members | 826 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,596 software developers and data experts.

Utillizing Reflection and Interfaces

Hello,

I was hoping my fellow coders would give me some feedback on the article
I wrote which makes use of the System.Reflection namespace and
Polymorphism to demonstrate how you can create dynamic and scalable
business objects.

http://www.developersdex.com/gurus/articles/739.asp

Thanks for your feedback, it's much appreciated.

Stefan
C# GURU
www.DotNETovation.com

*** Sent via Developersdex http://www.developersdex.com ***
Jan 7 '06 #1
2 2591
"Stefan" <we******@dotnetovation.com> a écrit dans le message de news:
uc*************@TK2MSFTNGP09.phx.gbl...

| I was hoping my fellow coders would give me some feedback on the article
| I wrote which makes use of the System.Reflection namespace and
| Polymorphism to demonstrate how you can create dynamic and scalable
| business objects.

Hi Stefan, Please don't take this as outright criticism of *how* you've
written the code, but I do have concerns about this approach of including
database behaviour in business class; it simply isn't necessary.

If you really want to create dynamic and scalable business objects then you
need to design an Object Persistence Framework or Data Access Layer. This
then completely separates the business concepts from the domain of
databases. Why do developers assume that the only method of storage, even
for small numbers of instances of classes should be a database ?

In a well-designed multi-tiered framework, business classes should only ever
be concerned with business logic; how they are to be persisted should be a
non-concern, from the business logic point of view.

Certainly, you need a means of examining an object in order to persist it,
and also a means of being able to create instances and populate them from
persisted state; but this should not impose one particular way of connecting
with the persisted state, however that is achieved.

..NET reflection allows you to interrogate the state of objects without any
special interfaces or base classes. If you require special treatment of
certain fields in a class, then you can apply attributes, but you could also
have a mapping hierarchy inside the OPF or DAL which allows you to specify
which fields are or are not persistable which fields in which table that
field is to be persisted in.

Your base class includes things that are relevant to lists of objects, but
they are defined as instance methods. This implies you need an instance of a
Customer in order to access a list of Customers !!?? At the very least, any
methods that relate to lists of the given class should be static so that
they can be used without an instance.

The only special features that need adding to a base business class are: a
dirty flag to indicate whether the object has been modified, possibly a
persisted flag to indicate whether this instance was retrieved from storage,
although even this can be deduced from the other "special" feature of a base
business class, which is the ID of the instance - if the ID is null then the
instance has not been persisted, as soon as it is persistent, the ID is set
to a valid value.

I have written a series of articles that discuss OPF techniques; they are
not complete, but should give you a good idea of some of the problems and
how they can be solved. www.carterconsulting.org.uk

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
Jan 7 '06 #2
Stefan,

You ask for comments on your article. I have read it and my conclusion
might not be of your liking, I am sorry. Since you ask for it I will
nontheless give a few very short comments on your rather trivial
article.

1. If you want to build some sort of O/R mapper with reflection you
might take a look at the code of NHibernate which does what you
intend to do with even less coupling( for what that means see the
reaction of Joanna)

2. If you want to make a real good O/R mapper try without reflection(
reflection beats any oo principle) and for instance create it like
COAD suggested in his appendix of Object Models. The essence being
almost independent PDObjects which might have a persistence interface
which in turn uses a singleton DMObject for their persistant
operations.

3. Be sure to study .net 2.0 since what you are doing is also probably
partly duplicating table adapters since table-object might in a lot of
cases be a 1-1 relation.
Rick


On Sat, 07 Jan 2006 03:40:22 -0800, Stefan
<we******@dotnetovation.com> wrote:
Hello,

I was hoping my fellow coders would give me some feedback on the article
I wrote which makes use of the System.Reflection namespace and
Polymorphism to demonstrate how you can create dynamic and scalable
business objects.

http://www.developersdex.com/gurus/articles/739.asp

Thanks for your feedback, it's much appreciated.

Stefan
C# GURU
www.DotNETovation.com

*** Sent via Developersdex http://www.developersdex.com ***


Jan 10 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by ichor | last post: by
3 posts views Thread by HL | last post: by
1 post views Thread by John F | last post: by
1 post views Thread by Big Daddy | last post: by
reply views Thread by XIAOLAOHU | last post: by
reply views Thread by leo001 | last post: by
reply views Thread by Anwar ali | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.