socamb a écrit :
> I have been developing for quite ssome time. Ever since .NET came out,
> i have hated datasets. I do not like the way field names are coded as
> strings and I do not like the way strongly typed datasets genertate
> tons of code.
>
> I have been using custom classes for by data access instead of
> datasets for quite some time. I get the strongly typed code I like
> without the overhead of strongly typed datasets.
>
> So, ORMs line NHibernate intrest me.
>
> The one thing I have not become comfortable with yet is allowing the
> ORM to generate the SQL necessary to access the database.
>
> I have always performed data access via procs when ever possible. I
> like the abstraction between the application code and the database
> code. This makes database performance problems easier to track down
> because all data access is doen via procs.
>
> I can also see some DBAs cringing at SQL generated by an application.
>
> I would appreciate thoughts on this matter.
>
> I look forward to understanding more about this topic.
>
> >
>
>
>
As architect, I would say that if you need to persist objects and want
to build your application on top of an OO model, an ORM is the right
solution.
--> the database will be created according your object model
If you need to access data, and all your logic is purely relational,
then the sps are the right choice and the ORM need is not real.
--> the application will behave according your sp.
meanwhile, nhibernate is transparent on the generated sql statements.
So, there is something every developper should check.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---
