http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Ah - never mind - reflecting around, I see that the job of this method is just to mutate the IDbCommand appropriately. http://ayende.com/3472/entities-dependencies-best-practices#comment48http://ayende.com/3472/entities-dependencies-best-practices#comment48Thu, 07 Aug 2008 14:18:10 GMTAyende, are you sure your below method is complete? Looks like it never actually persists anything: public void NullSafeSet(IDbCommand cmd, object value, int index) { object paramVal = DBNull.Value; if (value != null) paramVal = CryptoProvider.Instance.Encrypt((string) value); IDataParameter parameter = (IDataParameter)cmd.Parameters[index]; parameter.Value = paramVal; } http://ayende.com/3472/entities-dependencies-best-practices#comment47http://ayende.com/3472/entities-dependencies-best-practices#comment47Thu, 07 Aug 2008 14:06:57 GMTNo issue with that, the UserRepositoryImpl is another infrastructure service http://ayende.com/3472/entities-dependencies-best-practices#comment46http://ayende.com/3472/entities-dependencies-best-practices#comment46Mon, 04 Aug 2008 19:38:11 GMTAyende, what are your thoughts on using this approach versus setting up the dependencies in an implementation of IUserRepository? http://ayende.com/3472/entities-dependencies-best-practices#comment45http://ayende.com/3472/entities-dependencies-best-practices#comment45Mon, 04 Aug 2008 12:50:20 GMTNo, NHibernate doesn't support this. And I consider this an OK solution, because IUserType is part of the infrastructure http://ayende.com/3472/entities-dependencies-best-practices#comment44http://ayende.com/3472/entities-dependencies-best-practices#comment44Sun, 03 Aug 2008 21:53:34 GMTWhat if I wanted to pass in the CryptoProvider instance to the IUserType class via dependency injection instead of through static singleton? Does NHibernate support this? Or in this particular case, would having the IUserType class have a reference to the dependency container be "ok" practice? http://ayende.com/3472/entities-dependencies-best-practices#comment43http://ayende.com/3472/entities-dependencies-best-practices#comment43Sun, 03 Aug 2008 21:43:54 GMTPaul, You seem to be confusing the issue of needing to find a match and needing to get the data. Password vs. Email is the simple case. I don't care what your password is, I just need to match it: hash it. I don't want your email in clear text in my DB, but I still need to access it so I can send you stuff: encrypt it. http://ayende.com/3472/entities-dependencies-best-practices#comment42http://ayende.com/3472/entities-dependencies-best-practices#comment42Fri, 01 Aug 2008 10:36:23 GMT>> How do I get the email _back_ You cannot get the email back but it is the safest way. It all depends on the level of security you are after. You store the users password as encrypted in the database and when they come to log in, you encrypt their password input and check it against the database. It is not reversible and therefore the safest way. Saying that SHA1 is no longer deemed safe. We use SHA256. http://ayende.com/3472/entities-dependencies-best-practices#comment41http://ayende.com/3472/entities-dependencies-best-practices#comment41Fri, 01 Aug 2008 10:27:15 GMTPaul, One way encryption is fairly useless. How do I get the email _back_ ? http://ayende.com/3472/entities-dependencies-best-practices#comment40http://ayende.com/3472/entities-dependencies-best-practices#comment40Fri, 01 Aug 2008 10:17:01 GMTKrzysztof , Extending NH is the way to go in this scenario http://ayende.com/3472/entities-dependencies-best-practices#comment39http://ayende.com/3472/entities-dependencies-best-practices#comment39Fri, 01 Aug 2008 10:16:22 GMTShould encryption not be only one way? Is it not bad practice to have an algorithm that can be decrypted? http://ayende.com/3472/entities-dependencies-best-practices#comment38http://ayende.com/3472/entities-dependencies-best-practices#comment38Fri, 01 Aug 2008 07:41:09 GMT@Geoff Are you suggesting code like this? public class Customer { public Name Name { get; private set; } private Customer(){} //to satisfy NHibernate public Customer(Name name) {Name = name; } } Yes, this would get the job done, in this case. However it smells. I don't want to throw buzzwords at you, but now I have to design my entity having limitation of specific persisting framework in mind, whereas it should really be persistence agnostic. What will the next guy do, when he comes to change the code two years from now, when I'm long gone from that project? This approach simply can't guaranty that he won't change the field somewhere in his new added code, breaking my whole assumptions about it. Sure I can add NDepend rule to check that the field is modified only from within NHibernate and fail the build but it's really a lot of overhead to satisfy 3rd party framework in my domain model. No flames please :) Letting 3rd parties in would really be not a good idea, but maybe extending NHibernate to handle simple cases like that is a goal worth giving a thought? As for lazy loading, well, maybe I don't care about it that much. Maybe I always want to use Name wherever I use Customer so lazy loading does not make sense for it anyway? http://ayende.com/3472/entities-dependencies-best-practices#comment37http://ayende.com/3472/entities-dependencies-best-practices#comment37Fri, 01 Aug 2008 07:35:04 GMT@Krzysztof, Well, you're right there. :) However, what is the actual desired behaviour you're trying to achieve? Is it that a consumer of the class can't alter the property value or reference? Then relaxing the readonly requirement and adding the private setter might get you the desired result. http://ayende.com/3472/entities-dependencies-best-practices#comment36http://ayende.com/3472/entities-dependencies-best-practices#comment36Fri, 01 Aug 2008 06:22:17 GMT@Geoff would that work with readonly fields as well? i mean readonly as in 'c# readonly' keyword, not 'without public setter'. I'm afraid not. http://ayende.com/3472/entities-dependencies-best-practices#comment35http://ayende.com/3472/entities-dependencies-best-practices#comment35Fri, 01 Aug 2008 05:42:10 GMT@Krzysztof, Isn't there an option in the mapping files to tell it to populate an entity using the private backing fields? Mixed with Ayende's solution, would this not give you the behaviour you're looking for? http://ayende.com/3472/entities-dependencies-best-practices#comment34http://ayende.com/3472/entities-dependencies-best-practices#comment34Fri, 01 Aug 2008 04:17:57 GMTHmmmm, For last 10 minutes i've been trying hard to find a counter argument for that, but the more I thing about it, the more I see that given constraints current design is the best choice available. Thanks. And as a sidenote, it's yet another time when you answer a question fully and completely with one few-words sentence and there's not really much more to say after that. http://ayende.com/3472/entities-dependencies-best-practices#comment33http://ayende.com/3472/entities-dependencies-best-practices#comment33Thu, 31 Jul 2008 20:26:02 GMTKrzysztof, Yes, that is the way it works, and no, there isn't such option. consider the case of lazy loading an entity, for example http://ayende.com/3472/entities-dependencies-best-practices#comment32http://ayende.com/3472/entities-dependencies-best-practices#comment32Thu, 31 Jul 2008 20:11:56 GMT@Ayende I'm still unsure about this approach. If I understand it correctly from looking at method's signature and your above example all I get is string telling me the name of the type I'm asked to create, it's entity mode and id. If I have Customer data fetched from DB and I'm about to create one (assuming I have only one ctor: the one that takes CustomerName and Address) I can't create the customer since I don't have those two properties. The way I understand NHibernate's instantiation works is: 1. Get data from the DB 2. Do the IUserType conversions the way you showed in the last example 3. Create the object with default ctor. 4. Set fetched data to properties What I was asking about, is if it's possible to replace step 3 and 4 with other logic, like registering fetched dependencies and properties with Windsor and let it take care of instantiation (and selecting ctor that should be used). Does it make sense? http://ayende.com/3472/entities-dependencies-best-practices#comment31http://ayende.com/3472/entities-dependencies-best-practices#comment31Thu, 31 Jul 2008 20:10:08 GMTFrans, Yes, it has. IUserType :-) http://ayende.com/3472/entities-dependencies-best-practices#comment30http://ayende.com/3472/entities-dependencies-best-practices#comment30Thu, 31 Jul 2008 19:17:04 GMTIf you did what Stefan suggests, wouldn't you still need the ICryptoProvider dependency within an Entity. It would be in the EmailAddress entity instead of the User one. http://ayende.com/3472/entities-dependencies-best-practices#comment29http://ayende.com/3472/entities-dependencies-best-practices#comment29Thu, 31 Jul 2008 19:14:13 GMTWhy doesn't NHibernate have the feature like a typeconverter ? Then you can specify it in the mapping. The value is passed to the type converter by the o/r core the value returned is sent to the db .When the entity is fetched, the value is passed to the type converter and the value returned is placed in the entity. You can do encryption/decryption but also all kinds of nasty conversions you don't want to deal with at a class level, like 'Y'/N conversions to boolean if you want to work with booleans but have to work with Oracle for example. http://ayende.com/3472/entities-dependencies-best-practices#comment28http://ayende.com/3472/entities-dependencies-best-practices#comment28Thu, 31 Jul 2008 19:04:49 GMTStefan, That is an excellent suggestion! http://ayende.com/3472/entities-dependencies-best-practices#comment27http://ayende.com/3472/entities-dependencies-best-practices#comment27Thu, 31 Jul 2008 18:31:39 GMTWhy not make the email address a class of its own with encrypted and decrypted property getters? The NH mapping would map to the encrypted property, the application would access the decrypted one. This way the behaviour of the email address would be made explicit in the business doamin. http://ayende.com/3472/entities-dependencies-best-practices#comment26http://ayende.com/3472/entities-dependencies-best-practices#comment26Thu, 31 Jul 2008 18:27:20 GMTI would recommend changing that to a user type, yes http://ayende.com/3472/entities-dependencies-best-practices#comment25http://ayende.com/3472/entities-dependencies-best-practices#comment25Thu, 31 Jul 2008 18:26:42 GMTInteresting, in one project I am using AR and the AR Base and use events hooked in OnFlushDirty/BeforeSave to intercept properties and change their values before something is committed to the database. (I do this without putting these events in the entity classes themselves so it isn't that messy) I was under the impression that these methods in ARBase were fired via an NH interceptor. Is what I am doing a bad way of doing this? http://ayende.com/3472/entities-dependencies-best-practices#comment24http://ayende.com/3472/entities-dependencies-best-practices#comment24Thu, 31 Jul 2008 18:20:56 GMTThat is not what an interceptor is for. You could do it at the proxy factory level, though http://ayende.com/3472/entities-dependencies-best-practices#comment23http://ayende.com/3472/entities-dependencies-best-practices#comment23Thu, 31 Jul 2008 17:55:38 GMTWhat about creating an interceptor that encrypts / decrypts the fields for you? The interceptor could be driven either off of some configuration if you wanted to keep your POCOs clean or an [Encrypt] attribute if you didn't mind putting that sort of thing in your domain model. Would this be a reasonable solution? http://ayende.com/3472/entities-dependencies-best-practices#comment22http://ayende.com/3472/entities-dependencies-best-practices#comment22Thu, 31 Jul 2008 17:54:18 GMTIInterceptor.Instantiate is how you do it, doesn't take a lot of work http://ayende.com/3472/entities-dependencies-best-practices#comment21http://ayende.com/3472/entities-dependencies-best-practices#comment21Thu, 31 Jul 2008 17:41:52 GMT@Ayende Yes, I know that it does not require me to use IoC. but what if I don't want to have default ctor? For example I want my cannonical Customer Entity to have his Name and Address be read-only and as such - I can set them only in the ctor. I'm aware that there is some way of doing it, but IIUC it is per-entity-type solution and it requires quite a lot of work. Does it sound reasonable or am I approaching the problem from the wrong angle? http://ayende.com/3472/entities-dependencies-best-practices#comment20http://ayende.com/3472/entities-dependencies-best-practices#comment20Thu, 31 Jul 2008 17:06:27 GMTThat is a way, but IPA is not something that we intend for people to use. IUserType is http://ayende.com/3472/entities-dependencies-best-practices#comment19http://ayende.com/3472/entities-dependencies-best-practices#comment19Thu, 31 Jul 2008 16:51:21 GMT