Tech Off Thread

5 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Quickpoll: EntLib or Custom?

Back to Forum: Tech Off
  • User profile image
    vulgrin

    I'm in the middle of working on a couple "application blocks" of my own, that I'll likely release out to folks as open source.  These aren't true application blocks (at least not right now) in that they dont integrate with the rest of the EntLib framework, but I am architecting them to be as small a footprint as possible, with the least amount of external references as possible. 

    However, while I'm now in the middle of rolling my own simple DB layer for one of the blocks, I am fighting with myself about whether to build my own couple of small classes to handle my data access, or whether I should just buckle in and include the EntLib Data block and all of its built in features.

    So, quick poll: if you found a useful code block on CodeProject or elsewhere, that talks to your database would you rather:

    a) it used its own internal database code
    b) it integrated into EntLib.  (and only into EntLib)

    In both cases, it would come with the source, and in case (b) you would need to get a hold of EntLib and compile it in yourself.

    Let me know if this makes no sense. Smiley

  • User profile image
    Charles

    I'm not sure I understand what you're asking for, but here's what I'd advise based on this misunderstanding Smiley

    You should use the abstract data providers construct and give your consumers the flexibility that an abstract data layer provides. Channel 9, for example (and CommunityServer, of course),  implements an abstract data provider layer to handle all of our data access logic (we choose to only use one implementation, SqlDataProvider).

    I'd recommend reading the PAG literature on this topic located here.

    C

  • User profile image
    vulgrin

    I'm not sure I understand your reply in the context of my question. Smiley

    What I'm basically asking is:  As a consumer of my code block, would you rather I use the Data Block from EntLib, or roll my own, more concise, database layer?

    The Data Block has the bonus that its a) already written and b) sort of "standard" (depending upon who you talk to).    Of course, this comes with the price in that there are separate assemblies you need to get and keep track of and it has a larger footprint.

    The custom db layer has the advantage of being more targeted, smaller and not require external libraries, but is not standard and may not be as full featured later if you need it to be.



  • User profile image
    Tyler Brown

    I think what Charles is saying is that instead of a database layer, you should simply be implementing an abstract data provider layer. The layer is abstract because it specifies the basic functionality that must be met in order for the application to make use of the data provider layer. Developers can then come along and implement a solution to work with a specific data provider, such as an SQL database.

  • User profile image
    Yggdrasil

    vulgrin wrote:
    a) it used its own internal database code
    b) it integrated into EntLib.  (and only into EntLib)


    Had you asked this question a year ago, when the Application Blocks were PAG's offering, I would have given a definite "Go with the AppBlocks" answer - using the DAAB or EMAB would have been great for consistency and such.

    But with the new EntLib... I don't know. It's a great effort to gather all of them and standardize them, but I've been burned several times with it. The fact that you can't just plug it in and use it (the default assemblies, as compiled, require WMI providers and EventSource DLLs to be registered on the computer running it) was a major source of frustration, especially after getting used to xcopy deployment. It just got way too complicated to manage, especially if I only need something simple, like the Exception Management AB.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.