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.
--------------------------------------------------------
.
