By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
426,178 Members | 2,144 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 426,178 IT Pros & Developers. It's quick & easy.

Microsoft Enterprise Library

P: n/a
Is anyone using the Microsoft Enterprise Library? If yes, do you like it or
not?

Any feedback will be appreciated.

Nov 17 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
I'm currently using the MEL Data Access Application Block and find it
very useful. It provides a conveniently abstracted API for common
ADO.NET tasks.

The other blocks, however, i have had trouble configuring and using.

I've also had trouble compiling the designer code with all the required
resources, so my Configuration Manager application throws exceptions
that don't let me access all the design features.

Nov 17 '05 #2

P: n/a

"poifull" <po*******@yahoo.com> wrote in message
news:gg*******************@tornado.texas.rr.com...
Is anyone using the Microsoft Enterprise Library? If yes, do you like it
or not?

Any feedback will be appreciated.


We use the Microsoft Enterprise Library extensively at our organization. We
have found that it really does help us develop our code faster than
previously (mainly because we didn't write a library ourselves that helps
with data access, logging, configuration management, et cetera). Basically,
the Microsoft Enterprise Library has taken giant leaps since the initial
release awhile ago (SQLHelper). There is something missing from the
Enterprise Library that we miss dearly though.

Before we could write our Update methods like the following short snippet:

Public Sub Update(ByVal Row As StrongTypedDataRow)
SqlHelper.ExecuteNonQueryTypedParams( _
ConnectionString, _
"MyUpdateStoredProcName", _
Row _
)
End Sub

But now, I have to do something like the following using the new Enterprise
Library:

Public Sub Update(ByVal Row As StrongTypedDataRow)
Dim db As Database = DatabaseFactory.CreateDatabase()
Dim cmd As DBCommandWrapper = _
db.GetStoredProcedureCommandWrapper("MyUpdateStore dProcName")

cmd.AddInParameter("@CustomerId", DbTypeEnumValueHere, Row.CustomerId)

If Not Row.IsCustomerNameNull
cmd.AddInParameter("@CustomerName", DbTypes.String,
Row.CustomerName)
Else
cmd.AddInParameter("@CustomerName", DbTypes.String, DBNull.Value)
End If

If Not Row.IsCustomerAddressNull
cmd.AddInParameter("@CustomerAddress", DbTypes.String,
Row.CustomerAddress")
Else
cmd.AddInParameter("@CustomerAddress", DbTypes.String, DBNull.Value)
End If

cmd.AddInParameter("@RowVersion", DbTypes.SomethingHere, DBNull.Value)

db.ExecuteNonQuery(cmd)
End Sub

Anywho, method names may be a bit off, but you get the picture :)

The new version of the Data Access Application Blocks makes you write more
code than the old version.

Mythran
End Sub

Nov 17 '05 #3

P: n/a
If you really want to cut down on code for accessing a database you should
use the XmlSerializer object.

Check out what I did using XmlSerializer.
http://www.gbg-development.com/development.aspx
"Mythran" <ki********@hotmail.comREMOVETRAIL> wrote in message
news:eq**************@TK2MSFTNGP14.phx.gbl...

"poifull" <po*******@yahoo.com> wrote in message
news:gg*******************@tornado.texas.rr.com...
Is anyone using the Microsoft Enterprise Library? If yes, do you like it
or not?

Any feedback will be appreciated.


We use the Microsoft Enterprise Library extensively at our organization.
We have found that it really does help us develop our code faster than
previously (mainly because we didn't write a library ourselves that helps
with data access, logging, configuration management, et cetera).
Basically, the Microsoft Enterprise Library has taken giant leaps since
the initial release awhile ago (SQLHelper). There is something missing
from the Enterprise Library that we miss dearly though.

Before we could write our Update methods like the following short snippet:

Public Sub Update(ByVal Row As StrongTypedDataRow)
SqlHelper.ExecuteNonQueryTypedParams( _
ConnectionString, _
"MyUpdateStoredProcName", _
Row _
)
End Sub

But now, I have to do something like the following using the new
Enterprise Library:

Public Sub Update(ByVal Row As StrongTypedDataRow)
Dim db As Database = DatabaseFactory.CreateDatabase()
Dim cmd As DBCommandWrapper = _
db.GetStoredProcedureCommandWrapper("MyUpdateStore dProcName")

cmd.AddInParameter("@CustomerId", DbTypeEnumValueHere, Row.CustomerId)

If Not Row.IsCustomerNameNull
cmd.AddInParameter("@CustomerName", DbTypes.String,
Row.CustomerName)
Else
cmd.AddInParameter("@CustomerName", DbTypes.String, DBNull.Value)
End If

If Not Row.IsCustomerAddressNull
cmd.AddInParameter("@CustomerAddress", DbTypes.String,
Row.CustomerAddress")
Else
cmd.AddInParameter("@CustomerAddress", DbTypes.String,
DBNull.Value)
End If

cmd.AddInParameter("@RowVersion", DbTypes.SomethingHere, DBNull.Value)

db.ExecuteNonQuery(cmd)
End Sub

Anywho, method names may be a bit off, but you get the picture :)

The new version of the Data Access Application Blocks makes you write more
code than the old version.

Mythran
End Sub

Nov 17 '05 #4

P: n/a
I like the Data Access Block alone better.
It simplier than the Enterprise Library.

"poifull" <po*******@yahoo.com> wrote in message
news:gg*******************@tornado.texas.rr.com...
Is anyone using the Microsoft Enterprise Library? If yes, do you like it
or not?

Any feedback will be appreciated.

Nov 17 '05 #5

P: n/a
I do not like I spent about 2 weeks looking at it and I gave it a no go
at work. First I am not sold on web config base configurations I use
resx files to manage my build regions. It also just seems it is alot of
work to use. I ended up just writing my own Database library it took
less time then learning how to use Enterprise Application Blocks.
Really there is very little power in what they give you no more then
any developer worth his salt could write. I prefer NANT for building
and configuring applications and LOG4NET over they application blocks.
It is far more flexible I think.

Dont get me wrong I am happy that people are writing these things but I
think it is alot of over kill for most applications that I have delt
with.

Nov 17 '05 #6

P: n/a
there is a large learning curve but it pays off fairly well for very large
applications where the client absolutely demands configuration driven
products. I think the benefit (having worked with it) is that it allows
developers to build sophisticated apps that are extremely loosely coupled.
The trade offs are obvious but the gains may not be.

--
Regards,
Alvin Bruney - ASP.NET MVP

[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
Now available @ www.lulu.com/owc, Amazon.com etc
<pi****@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
I do not like I spent about 2 weeks looking at it and I gave it a no go
at work. First I am not sold on web config base configurations I use
resx files to manage my build regions. It also just seems it is alot of
work to use. I ended up just writing my own Database library it took
less time then learning how to use Enterprise Application Blocks.
Really there is very little power in what they give you no more then
any developer worth his salt could write. I prefer NANT for building
and configuring applications and LOG4NET over they application blocks.
It is far more flexible I think.

Dont get me wrong I am happy that people are writing these things but I
think it is alot of over kill for most applications that I have delt
with.

Nov 17 '05 #7

P: n/a
Will we get Enterprise Library for VS .NET 2005?

"Alvin Bruney [MVP - ASP.NET]" <www.lulu.com/owc> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
there is a large learning curve but it pays off fairly well for very large
applications where the client absolutely demands configuration driven
products. I think the benefit (having worked with it) is that it allows
developers to build sophisticated apps that are extremely loosely coupled.
The trade offs are obvious but the gains may not be.

--
Regards,
Alvin Bruney - ASP.NET MVP

[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
Now available @ www.lulu.com/owc, Amazon.com etc
<pi****@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
I do not like I spent about 2 weeks looking at it and I gave it a no go
at work. First I am not sold on web config base configurations I use
resx files to manage my build regions. It also just seems it is alot of
work to use. I ended up just writing my own Database library it took
less time then learning how to use Enterprise Application Blocks.
Really there is very little power in what they give you no more then
any developer worth his salt could write. I prefer NANT for building
and configuring applications and LOG4NET over they application blocks.
It is far more flexible I think.

Dont get me wrong I am happy that people are writing these things but I
think it is alot of over kill for most applications that I have delt
with.


Nov 17 '05 #8

P: n/a
I agree. I have been using the configuration and exception blocks and they
work great. I do have a question thought with portability with VS 2005 / and
or .net 2.0. Is there a enterprise library / application blocks for VS 2005 ?
I have various compiler errors with the 2005 beta version. Thanks for the
help.

"Alvin Bruney [MVP - ASP.NET]" wrote:
there is a large learning curve but it pays off fairly well for very large
applications where the client absolutely demands configuration driven
products. I think the benefit (having worked with it) is that it allows
developers to build sophisticated apps that are extremely loosely coupled.
The trade offs are obvious but the gains may not be.

--
Regards,
Alvin Bruney - ASP.NET MVP

[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
Now available @ www.lulu.com/owc, Amazon.com etc
<pi****@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
I do not like I spent about 2 weeks looking at it and I gave it a no go
at work. First I am not sold on web config base configurations I use
resx files to manage my build regions. It also just seems it is alot of
work to use. I ended up just writing my own Database library it took
less time then learning how to use Enterprise Application Blocks.
Really there is very little power in what they give you no more then
any developer worth his salt could write. I prefer NANT for building
and configuring applications and LOG4NET over they application blocks.
It is far more flexible I think.

Dont get me wrong I am happy that people are writing these things but I
think it is alot of over kill for most applications that I have delt
with.


Nov 17 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.