Re: An Abstraction Too Far??
- From: "RichB" <richb@xxxxxxxxxxxxxxxx>
- Date: Thu, 12 Jun 2008 13:55:09 +0100
OK Thanks Tim I think that I get it. I'm only reallly geting to grips with c#1, with a bit of use of the generics collections in v.2, so I haven't even looked at v.3.
Having said that I've taken a peak this morning at some information on extensions and now have a little understanding. However I'm not sure how you would stucture the assemblies and references between assemblies without having illegal circular referencing.
It is probably all my lack of understanding and I think that I am going to stick with my original approach. However if you want to discuss further, then please feel free to walk me through a fuller example.
Richard
"Tim Jarvis" <tim@xxxxxxxxxxxxx> wrote in message news:ufR3BKBzIHA.6096@xxxxxxxxxxxxxxxxxxxxxxx
RichB wrote:
Tim,
Sorry that I hadn't responded sooner, but I needed to sit down and
think about the problem subsequent in the light of the response from
Alun.
No Probs
I got a little lost in your response, but I am looking at this with a
pretty simple mind. In your example it appears that Customer is
effectivly a DTO, so all data and no behaviour, then is your
Ah, not meant to be a DTO, I just didn't add any behaviour in the
example but that would be the intention.
CustomerDataAccessExtensions within your Data Access Layer. The
method within that class is a little odd and perhaps needs some
explanation:
public static void Load(this Customer c)
Firstly, I am not sure what the 'this' is doing... I assume that the
method takes a Customer object as a parameter and is responsible for
loading the data to the database?
Sorry I had assumed that most people had come across extension methods,
in hindsight thats a bad assumption, they are pretty new still. This
method uses the keyword "this" in a special way, it will extend the
Customer class with a new instance method (in this case, Load), the
consumer of Customer would use it like this...
Customer cust = new Customer();
cust.Load();
In this case the load method is used to populate the Customer class,
the extension class would also have a corresponding Save method.
(doesn't have to be Load and Save of course, it could be Sync etc)
If I have misunderstood your post then please provide a little more
to your example to explain further, otherwise I would be interested
in any furthe thoughts that you or anyone else might have.
I guess what I am saying in a nutshell, is that I also favour layering
an app along Business Object and Data Access lines, I wouldn't have
data access objects separate from my business objects, I think that is
as you asked an abstraction one to many. And now with extension
methods, you can make the layers appear to disappear, effectively
hiding another level of abstraction ;-) this makes programming against
the model very simple and intuative for consumers of the Business
Objects, and that translates to easy to maintain.
Regards Tim.
--
.
- References:
- Re: An Abstraction Too Far??
- From: Tim Jarvis
- Re: An Abstraction Too Far??
- From: RichB
- Re: An Abstraction Too Far??
- From: Tim Jarvis
- Re: An Abstraction Too Far??
- Prev by Date: Re: Use of SynchronizationContext question
- Next by Date: Help with enums
- Previous by thread: Re: An Abstraction Too Far??
- Next by thread: Way to get BindingList<T> removed item?
- Index(es):
Relevant Pages
|
