Desktop Application Data Access Layer

  • Thread starter Thread starter BotRot
  • Start date Start date
B

BotRot

Hello C#.NET Forum,

I have a desktop application, (very) near completion. The application is
constructed in C# .NET 3.5 SP1, and the application files produced by the
application are MS Access 2007 Database (with the extension changed to suit the
application. The application file only consists of tables and relationships,
specifically for the application's purposes.

Generally there are two separate tiers for the data, a DataBroker which managers
the OleDb functionality specifically for MS Access, and a more "strongly" Data
Access Layer that utilises the data DataBroker, and serves the Business Tiers.

I decided (hopefully not incorrectly) to make the DataBroker instancing (as in not
like other DAAL helper class that perform on servers, as static).

My questions are basically, would it be better to;

1) Have my AccessHelper (in my DataBroker) as static? Then using it in my Strong
Typed Data Layer's classes


2) Have AccessHelper as instancing, and in my "strongly" Typed Data Layer, wrap it
in a singleton class, and use the singleton instance in my Typed Data Layer's
classes?


3) Have AccessHelper as instancing, and in my "strongly" typed Data Layer, wrap it
in a static class, and use the singleton in my Strong Data Layer's classes?


At the moment I have implemented (almost finished) number 2). My main reason for
asking is cause I'm always seeking the best way to implement a design. Googling
this topic yield lots of developers, each implementing either 1), 2), or 3), each
having very good reasons for doing so, can they all be the best way? Given this
as a desktop app, one application instance per application file.

Thanks and regards,
- BotRot
 
I'll second the linq idea by Arnold.

I would add that If I had my way I would make "renamed access
databases as a save file format" a criminal offence.

Seriously, too many startups do this and it causes nothing but strife.
Especialy if your selling the aplication to mom and pop / soho
clients. You will quickly find many things go wrong here that you did
not test for and many different machine configurations out there in
the wild will cause you greif. You do not need the support overheads
and crap that typicaly comes with this kind of shenadiganry.

An aditional advantage of LINQ is tha ability to store your data to
XML with brutal simplicity and rip it out again just as easy. You may
find you can completly decouple yourself from access, which is always
good.

Also your development time with LINQ code is much much quicker if your
a good programmer. If you are constantly debuging your code however
LINQ may get in your way.

Just my $0.00 and wild thoughts based on a small glimse of your
situation.

-Wazza
 
| If I was going to do this, then I would use Alinq a LINQ provider
| against the Access Database.
|
| http://www.alinq.org/en/default.aspx
|
| Why would I use Alinq? It would allow me to use a virtual database, a
| model based on objects, ORM, and LINQ with OOPs more effectively.


**************************************
I've been told far too many bad stories with Alinq, whether there true or not, I'm
not going near them. Especially regarding support.
I'll leave the rest of the sales pitch unread. After reading the next first few
lines I'm sure a Google search would bring it up Verbatim.
**************************************


|
| What is Language Integrated Query?
|
| LINQ is a Microsoft .NET Framework component that adds native data
| querying capabilities to .NET languages.
|
| Microsoft LINQ defines a set of query operators that can be used to
| query, project and filter data in arrays, enumerable classes, XML,
| relational database, and third party data sources. While it allows any
| data source to be queried, it requires that the data be encapsulated as
| objects. So, if the data source does not natively store data as objects,
| the data must be mapped to the object domain. Queries written using the
| query operators are executed either by the LINQ query processing engine
| or, via an extension mechanism, handed over to LINQ providers which
| either implement a separate query processing engine or translate to a
| different format to be executed on a separate data store (such as on a
| database server as SQL queries). The results of a query are returned as
| a collection of in-memory objects that can be enumerated using a
| standard iterator function such as C#'s foreach.
|
| Many of the concepts that LINQ has introduced were originally tested in
| Microsoft's C? research project. LINQ was released as a part of .NET
| Framework 3.5 on November 19, 2007.
|
| http://en.wikipedia.org/wiki/Language_Integrated_Query
|
| What is Object Relational Mapping?
|
| (ORM) is a programming technique for converting data between
| incompatible type systems in relational databases and object-oriented
| programming languages. This creates, in effect, a "virtual object
| database," which can be used from within the programming language. There
| are both free and commercial packages available that perform
| object-relational mapping, although some programmers opt to create their
| own ORM tools.
|
| http://en.wikipedia.org/wiki/O-RM
|
| http://www.objectmatter.com/vbsf/docs/maptool/ormapping.html
|
|
| What is Model-View-Presenter?
|
| MVP is a software pattern considered a derivative of the
| Model-view-controller.
|
| http://en.wikipedia.org/wiki/Model_View_Presenter
|
|
| MODEL-VIEW-PRESENTER
|
| http://www.polymorphicpodcast.com/
|
| click 'Shows'
|
| click 'Design Patterns Bootcamp: Model View * Patterns*
|
| view parts 1-5
|
|
| This is another type of design.
|
| UI
| MVP -- with MVP being used for a Windows Web or desktop UI solution
| BLL
| DAL
| Database Model.
|
|
|
|
|
|
 
Back
Top