I suppose you could look at it like entity and session beans. (Although
I do a fair amount of Java, I've successfully dodged J2EE so I don't
work with entity and session beans). We use that design pattern here
since a fair amount of what we're doing now ends up getting exposed as
web services so if we use this approach it works fine if an in memory
apps needs to use the entity objects and manage them and also works for
exposing a web service. As an example:
Class Company
Property Id { get; set; }
Property Name { get; set; }
Class CompanyService
Public Company GetCompany(String id)
{
//do iBatis stuff to retrieve data.
}
Public void Save(Company comp)
{
//validate using a Validator class
//do iBatis stuff
}
Hopefully you get the idea. For each service we create an interface so
that the implementation can be swapped out. This also allows us to hide
iBatis from other areas without requiring a framework to do that.
Hopefully this makes sense.
-----Original Message-----
From: Garth Keesler [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 8:13 AM
To: [email protected]
Subject: Re: Using QueryforObject in Constructor
It sounds like you're implementing Entity and Session Beans in C#,
something I am interested in doing myself. I take it your "session"
beans invoke the necessary iBatis methods to cause instantiation of the
classes? Interesting. It just seemed to me that the right place to put
instantiation code was in the constructor methods for the various
classes. Thats all the code I intend to put there: constructors and a
"Save" method that intelligently determines if a save is necessary
(isDirty ?), and is it an insert (isNew?) or an update.
Fun stuff! :-)
Thanx,
Garth
Clough, Samuel (USPC.PRG.Atlanta) wrote:
> I've seen (and used) that approach in the past, but more recently I'm
> seeing (and using) a service/data access layer more than that
approach.
> On our projects here, for example, Business Objects/Model
Objects/Domain
> objects whatever you want to call them are only data structures and we
> implement all functionality in other classes. In your example, the
> company object would have no logic in it for anything other than being
a
> data structure, so in most cases the Company object would only be an
> object with some properties and no real methods. Instead you have a
> CompanyService or CompanyManager (or whatever you want to call it)
that
> has a method called GetCustomer(string cid);
>
> This makes your application more modular. It's also very easy to find
> specific points of logic and it's very easy to plugin mocks or
different
> data access routines. Overall it seems cleaner to me. We even break
up
> validation and business rules into separate classes.
>
> Hope that helps.
>
> -----Original Message-----
> From: Garth Keesler [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 21, 2007 7:00 AM
> To: [email protected]
> Subject: Re: Using QueryforObject in Constructor
>
> Like I said, I'm new to iBatisNet. :-) I'm aware of mock objects but
> have never used them. This just seemed the "correct" approach; hiding
> the iBatis stuff in places that it made sense.
>
> BTW, I did get it to work as follows:
>
> // public constructor for Company accepting string as key
> Public Company(string CID)
> {
> ISqlMapper mapper = MYLib.Mapper.Instance();
> mapper.QueryforObject("selectCompany", CID, this);
> }
>
> Works just like I wanted.
>
> Thanx,
> Garth
>
> Arjen Smits wrote:
>
>> What u want to do is not possible with C#, like u said u will need to
>> create an temporal instance and then assign the fields using the
>> temporal object.
>>
>> However, why would u want to do this in the constructor? It seems
abit
>> like a bad idea to me. Because basically you are robbing yourself of
>>
> the
>
>> ability to create mock objects.. using that constructor that is..
>>
>> Delegating the creation of your objects to other classes (which
>> instantiate and initialise the object) seems like a much more
sensible
>> solution.
>> So I am curious as to why you would want an solution as this :)
>>
>> Arjen
>>
>>
>> ProPlanet BV
>> Rijnstraat 495F
>> 5215 EJ 's-Hertogenbosch
>> The Netherlands
>> Tel +31 (0)73 513 0637
>> Fax +31 (0)73 631 2114
>> www.proplanet.eu
>>
>> Disclaimer
>>
>> This e-mail and any attachment(s) sent with it are intended
>>
> exclusively for
>
>> the addressee(s), and may not be used by, opened by, passed on to, or
>>
> made
>
>> available for use to, any person other than the addressee(s).
>>
> ProPlanet rules
>
>> out any and all liabilities resulting from any electronic
>>
> transmission.
>
>> -----Oorspronkelijk bericht-----
>>
>> Van: Garth Keesler [mailto:[EMAIL PROTECTED]
>> Verzonden: woensdag 21 februari 2007 11:13
>> Aan: iBatis Net
>> Onderwerp: Using QueryforObject in Constructor
>>
>> Brand new to iBatis C#. I'd like to use the QueryforObject method
>>
> within
>
>> the constructor method for each class so the iBatis logic is
>>
> contained
>
>> within the standard approach to instantiating objects in C#. Prob is,
>>
> a
>
>> constructor already has the object created. Is it necessary to create
>>
> a
>
>> temporary instance using QfO and then to assign the fields from it to
>> the constructor-created instance? I must be missing something really
>> simple.
>>
>> Thanx,
>> Garth
>>
>>
>> .
>>
>>
>>
> --------------------------------------------------------
>
> Princeton Retirement Group, Inc - Important Terms
> This E-mail is not intended for distribution to, or use by, any person
or entity in any location where such distribution or use would be
contrary to law or regulation, or which would subject Princeton
Retirement Group, Inc. or any affiliate to any registration requirement
within such location.
> This E-mail may contain privileged or confidential information or may
otherwise be protected by work product immunity or other legal rules. No
confidentiality or privilege is waived or lost by any mistransmission.
Access, copying or re-use of information by non-intended or
non-authorized recipients is prohibited. If you are not an intended
recipient of this E-mail, please notify the sender, delete it and do not
read, act upon, print, disclose, copy, retain or redistribute any
portion of this E-mail.
> The transmission and content of this E-mail cannot be guaranteed to be
secure or error-free. Therefore, we cannot represent that the
information in this E-mail is complete, accurate, uncorrupted, timely or
free of viruses, and Princeton Retirement Group, Inc. cannot accept any
liability for E-mails that have been altered in the course of delivery.
Princeton Retirement Group, Inc. reserves the right to monitor, review
and retain all electronic communications, including E-mail, traveling
through its networks and systems (subject to and in accordance with
local laws). If any of your details are incorrect or if you no longer
wish to receive mailings such as this by E-mail please contact the
sender by reply E-mail.
>
> --------------------------------------------------------
>
>
> .
>
>
