"I don't know what are you talking about. BLToolkit has very good support of stored procedures. Without any restrictions."
I didn't mention BLToolkit, and it's very different from NHibernate and other OR-mappers. I do believe that it could be a good fit for you (or one of the micro-ORMs, like Dapper), if your main goal is to have cleaner data access. Best regards Gunnar 2013/4/30 <[email protected]> > Well, I just need to simplify my work. As i said before: for now, I'm > using ADO.NET with DataTables, DataSets etc. I'm tired to go with it. > I would like to deal with objects and as you said: "how can I use objects > to store and query things that are in my database" - is maybe my choice. > > Even those OR-mappers who claim otherwise will usually be a bit fiddly >> when it comes to stored procedures, imposing things like naming >> restrictions, all-or-nothing (all CRUD operations must be either non-SP or >> SP) etc. > > > > I don't know what are you talking about. BLToolkit has very good support > of stored procedures. Without any restrictions. > > I liked NHibernate. I've read a tons of articles about it. I like it's > very good extensibility. But I don't know how to do what I need. As I > understand: NHibernate is very good for web applications but not a desktop > (which has to deal with sp). > > A good article, if it wasn't for the "main advantage" being "Execution >> Plan Retention and Reuse can only be achieved using Stored Procedure", >> which is just plain untrue, and it was untrue in 2007 as well. > > > Yes. I'm fully agree with you. > > > I hope, I will migrate to BLToolkit with less pain. > > > > Вівторок, 30 квітня 2013 р. 01:39:12 UTC+3 користувач Gunnar Liljas > написав: >> >> "You may ask - why it can not deal with the application itself? Because >> of Reverse-Engineering (every-one can see .net code by using ILSpy or >> Reflector tool). And begin to connect to the server using something such as >> "Management Studio" and do everything that pleases. And that's just the >> above-mentioned mechanism will not allow him to do so." >> >> Fair enough. That's a perfectly fine reason to use stored procedures. >> However, the vast majority of OR-mappers are heavily geared towards solving >> the problem "how can I use a database to store and query my objects", not >> "how can I use objects to store and query things that are in my database". >> Even those OR-mappers who claim otherwise will usually be a bit fiddly when >> it comes to stored procedures, imposing things like naming restrictions, >> all-or-nothing (all CRUD operations must be either non-SP or SP) etc. >> NHibernate may not be the best of the bunch, but it's certainly one of the >> best. >> >> In this particular case, the problem really isn't stored procedures, but >> instead being able to get a DB generated value back to NHibernate, and >> Pete's suggestion solves just that. >> >> "And by the way: "sql server - stored procedures advantages and best >> advantage" [ >> http://blog.sqlauthority.com/2007/04/13/sql-server-stored-procedures-advantages-and-best-advantage/ >> ]" >> >> A good article, if it wasn't for the "main advantage" being "Execution >> Plan Retention and Reuse can only be achieved using Stored Procedure", >> which is just plain untrue, and it was untrue in 2007 as well. >> >> /G >> >> >> 2013/4/29 <[email protected]> >> >> "The bit I'm struggling to understand is why you need to use a stored >>>> procedure for the insert operation" >>> >>> >>> OK. Let me explain something. >>> >>> 1. My application is WinForm type. >>> 2. It uses mssql-server built-in security mechanism. Everyone has the >>> appropriate sql-server user. Each user assigning specific sql-server roles. >>> Which in turn have the right to execute certain stored procedures. >>> 3. In the stored procedure it is possible to examine additional security >>> conditions (for example, possibility of the user to create(insert) document >>> by additional condition) and to perform additional operation. >>> >>> You may ask - why it can not deal with the application itself? Because >>> of Reverse-Engineering (every-one can see .net code by using ILSpy or >>> Reflector tool). And begin to connect to the server using something such as >>> "Management Studio" and do everything that pleases. And that's just the >>> above-mentioned mechanism will not allow him to do so. >>> >>> And by the way: "sql server - stored procedures advantages and best >>> advantage" [ >>> http://blog.sqlauthority.com/2007/04/13/sql-server-stored-procedures-advantages-and-best-advantage/ >>> ] >>> >>> >>> If that isn't the case then I think that your initial requirement >>>> (population of the CreateDate column by the DB server) can easily be met by >>>> just mapping the CreateDate property as 'generated' and applying a default >>>> to the column? >>> >>> >>> >>> I knew nothing about this feature. But thanks any way. >>> >>> >>> So, am I do something wrong? How do you make security strength and >>> performance applications? >>> >>> >>> Понеділок, 29 квітня 2013 р. 17:25:20 UTC+3 користувач PeteA написав: >>> >>>> The bit I'm struggling to understand is why you need to use a stored >>>> procedure for the insert operation - is there a lot of logic in this >>>> procedure that's hard to handle elsewhere? If that isn't the case then I >>>> think that your initial requirement (population of the CreateDate column by >>>> the DB server) can easily be met by just mapping the CreateDate property as >>>> 'generated' and applying a default to the column? >>>> >>>> >>>> -----Original Message----- >>>> From: [email protected] on behalf of [email protected] >>>> Sent: Mon 4/29/2013 8:26 AM >>>> To: [email protected] >>>> Subject: [nhusers] Re: OUTPUT parameters in stored procedure. >>>> >>>> OK >>>> >>>> I asked "why???" because I really didn't understand why. >>>> >>>> I have another idea how to retrieve what we want and don't use OUTPUT >>>> parameters. >>>> What if to sql-insert add another attribute (list of properties). >>>> Example (mapping by code): >>>> >>>> m.SqlInsert("exec dbo.document_insert ?,?,?,?,?", new[] { >>>> t.CreateDate, t.EditDate }); >>>> >>>> And at the end of "document_insert" write this: >>>> >>>> SELECT SCOPE_IDENTITY, @CreateDate, @EditDate >>>> >>>> >>>> I think it's elegant way of problem solving. >>>> >>>> So, what will you say? >>>> >>>> >>>> ?????????, 22 ?????? 2013 ?. 22:08:42 UTC+3 ?????????? >>>> [email protected] ???????: >>>> >>>> I know nhibernate doesn't support output parameters? but I >>>> don't understand why. >>>> >>>> Why I can't write something like this: >>>> >>>> <class name="Document"> >>>> ... >>>> <sql-insert>exec createDocument ?,? OUT,?,?</sql-insert> >>>> ... >>>> </class> >>>> >>>> I think it's very easy to implement. >>>> >>>> Now, for data access code I'm using pure ADO.NET. And my >>>> "documents" table has "CreateDate" column, which is set by server, and >>>> returns to my application by output parameter of stored procedure. >>>> I know I can set "CreateDate" property of my POCO class >>>> manually but i don't want do it because I can't accurately synchronize >>>> client clock to the clock of server. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "nhusers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/nhusers?hl=en-US. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "nhusers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/nhusers?hl=en-US. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/nhusers?hl=en-US. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
