I developing an application.
I read somewhere that database should not be accessed directly but there should be kind of layer and via it database should be accessed.
I don't know the exact reason.
It will be great if you can provide me some reasoning or links to follow.
Yes it is really a good practice to abstract/encapsulate your DB access logic from other part o. Data access layer should not be accessed directly or exposed to everyone. Meaning when you are designing an application, you must consider this important factor “Layered architecture” for example business layer, service layer, presentation layer and whatsoever. The work flow like service layer (if its web application) calls business layer and business layer calls data access layer. All this layers should be very abstracted to each other or it should be accessible only to the very immediate layer (so called clients).
Answer to your question: Let’s say your current data access implementation is based on plain JDBC/ODBC .After some time when your requirements grow; you are planning to implement it with some ORM framework. In this case it’s really easy to switch/migrate between different data access logic written in different APIs without affecting rest of your application and still other layers are not aware of your changes since your design is very abstracted in nature.
Bottom Line: Always work against abstracted interface rather against implementation.
Hope this is helpful and comments are appreciated
Related
Should we use webservices or do direct database access. Ofcourse direct DB access is relatively faster and also with webservices it is good if we have to make for multiple platforms.
is the time significantly high in case of accessing data through a webservice as against a DB call or is it marginally high ?
I would have to disagree with TruthOf42 in that web services are best practices for data access. There is certainly a big shift towards that approach these days, but I don't think common use is the same as best practice. Just because something is common/popular doesn't mean it's the best fit for all situations.
Why use web services?
If you plan on having more than one application use a generic data access layer.
If you plan on exposing your data to external clients.
If you want to draw some hard physical lines between your application and the database.
I would argue making web service calls will always be slower than just writing queries against the database. But you can mitigate the issues with wise network planning and caching.
I agree with Aphelion in that if it's a simple application, then keep it simple.
A good idea would be to make an interface in your code that gets data and you start with a database implementation. If you find you'd like to introduce web services later, then you can keep the same interface and just implement a version that makes web service calls instead of directly dialing the database.
Don't try to optimize something you haven't even written yet. It's best practices to use web services. Doing direct calls to the database just opens you to more security issues.
The most important thing when writing software is writing it well, speed is usually of last concern.
If my question isn't clear, please help me improve it with comments.
I'm new to Delphi and dbExpress and I'm just getting acquaintance with TSQLDataset, TDataSetProvider, TClientDataSet and TDataSource classes.
The project that I'm working on uses this components in a way that feels strange to me. There is a huge data module unit that contains lots and lots of the quartet of classes previously described. I'm guessing that there are better (and more modularized) ways of doing this. DataSnap is used only to place this data module in a server application, so the clients access the data through it.
So, let me try to explain some of my doubts:
What is the role of each one of this classes? I read the documentation but I can't get a practical insight on this subject (specially about TDataSetProvider).
Which classes should be in the data module and which should be in my forms?
Is it possible to create an intermediate layer to abstract my business model from my database setup (maybe creating functions that return immutable datasets?)?
If so, is it wise to use DataSnap to do so?
I'm sorry if I'm not clear enough. Thanks in advance.
Components
TDataSource is the bridge between data-aware controls and the dataset (TDataSet descendant) from which they are to get their values.
TClientDataSet is one such dataset. TClientDataSet can be used in isolation, for example to access data contained in xml files, but can also be hooked up to a TDataSetProvider.
TDataSetProvider is the bridge between the in-memory TClientDataSet and the actual dataset that takes its data from a database through some kind of driver. In Client Server development you will usually see a TRemoteDataSetProvider (name may be different, I don't work with these components that often), which bridges the gap between the client and server.
TSQLDataSet is the actual dataset getting its data from some database.
It would feel strange to me to see this quartet all in one executable. I would expect the TSQLDataSet on the server side hooked up to the TRemoteDataSetProvider's counter part. However, I guess that with an embedded database it could be a way to support the briefcase model, which is where TClientDataSet is really helpful (TClientDataset is very powerful, that is just one of its strong points.)
Single datamodule
Ouch. A single huge datamodule is lazy programming or the result of misconceptions about how to use datamodules. It is perfectly normal to have a single datamodule that "hosts" the database connection which is then used by various other datamodules that are more tightly focused on aspects of the application.
Domain abstraction
With regard to abstracting your business model, dbexpress and datasnap should really not be anywhere in your business model. They should be part of your data layer.
TDataSource, TClientDataSet and custom TDataSetProvider descendant(s) can be used to leverage the power of the data-aware controls in the UI while still keeping the UI separate from the business model. In this case the custom TDataSetProvider would be the bridge between the client dataset and the collections and instances in the domain layer.
Even so, I would still expect to see a separate data layer, using TRemoteDataSetProviders or straight TDataSet descendants (like TSQLDataSet) to provide the domain layer with its data.
The single huge data module you mentioned could be part of that data layer, with the client datasets providing the business layer with its data. As you also mention TDataSource as part of a common quartet, the application was probably developed in a RAD-data-aware fashion where UI controls are basically hooked up straight to database columns/tables.
If you want to transform this application to have a more layered architecture, tread carefully and slowly. Get to know the current architecture first and get to know it well enough to see the impact that this kind of transformation would have. The links provided by Serg will certainly help you there. Pawel Glowacki has written extensively about DataSnap.
The project you are working on is a Delphi Multitier Database Application
Your question is too wide for SO and hardly can be answered in its current form - you should learn to understand the underlying architecture.
You can start from video tutorial by Pawel Glowacki:
http://www.youtube.com/watch?v=B4uxLLIUddg
http://cc.embarcadero.com/item/28188
I will start to develop an application that has to access to database. What kind of design patterns area usually need to be implemented to make my application more flexible for example changing DB client from SQL to Oracle.
I believe to perform execution of some query I can implement Template Method Pattern. And to get connection a singleton pattern with double check would be sufficient.
Is there anything else I should know before starting?
Application will be developed in C#, so there is support for object inheritance and polymorphism.
Any help is appreciated.
Make sure all your code is encapsulated in a data access layer. Code against interfaces so that if you need to write a new data access library, you don't have to change all calling code. This will at least isolate all data access into on library. How likely is the changing of database to be? Don't make the software complex for the what-ifs as this will just make life more difficult.
Abstract something 'on-fly' and only when You can clearly see a benefit.
Otherwise - that's just waste of time.
Do not think like:
I should use pattern [x] because it might fix [y]
Think like this:
Oh crap, again got to write same stuff. Let's see how we could avoid that...
There's a good design pattern called Data Access Object, you will have to incorporate it into C#.
Summary:
The DAO implements the access
mechanism required to work with the
data source. The data source could be
a persistent store like an RDBMS, an
external service like a B2B exchange,
a repository like an LDAP database, or
a business service accessed via CORBA
Internet Inter-ORB Protocol (IIOP) or
low-level sockets. The business
component that relies on the DAO uses
the simpler interface exposed by the
DAO for its clients. The DAO
completely hides the data source
implementation details from its
clients. Because the interface exposed
by the DAO to clients does not change
when the underlying data source
implementation changes, this pattern
allows the DAO to adapt to different
storage schemes without affecting its
clients or business components.
Essentially, the DAO acts as an
adapter between the component and the
data source.
Check the Catalog of Patterns of Enterprise Application Architecture by Martin Fowler.
You may find a few good ideas there.
you should investigate the user of the data mapper pattern to keep the implementation details of how your data is stored (SQL/Oracele/Access) independent from the use of the data itself.
http://martinfowler.com/eaaCatalog/dataMapper.html
In a RIA application you are supposed to put as much business logic as possible outside of the RIA layers (flash/silverlight etc). What is the reason behind this? Any logic that goes into the presentation tier gets the benefit of executing faster...
Is this because the RIA technology will most likely need a face lift down the road and you will have to rewrite all the business logic?
I'm not sure I agree with your premise, that you're "supposed" to put business logic outside the client. You are supposed to move the business logic outside the UI layer, but there are typically still a couple client-side layers left before you hit the back-end web service. A typical Silverlight application, for instance, is based on the MVVM model, which prescribes a View that has no business logic, a ViewModel which has a pretty good chunk of validation and business logic, and a model, which has the rest. And all of that is on the client side.
On the other hand, you really need a business logic layer on the server as well. You can't rely on a client-side application to filter out all the bad data: someone might be running an old version of the client, or a different client entirely, or might be trying to hack your system.
In other words, ideally, you should have your business logic and validations executing on both the client and on the server: on the client, because you need responsiveness, and on the server, because you need security. The question is how to get this, and there aren't any perfect answers.
One approach commonly taken in Silverlight applications (I'm less familiar with Flash) is to use WCF RIA services, which allows you to create validations in one place that are executed on both the client and server. Even if you're not using the WCF RIA Services framework, you can still get much of the same effect by linking to the source code of your validation/business logic classes on both the client and on the web service -- it's more work, but still probably less work than writing your validations twice and keeping them in sync manually.
Business Logic is a cross-cutting concern.
Will your users be entering dates? If so, the interface needs to know they are dates to give them a picker, and to prevent invalid entries. Maybe even restrict entries to a range. That is business logic. How can you keep it out and still have a meaningful interface?
Will users be entering at any time a US State or a Province? If so, the drop-down list will have to be populated, and that means the UI "knows" about foreign keys.
Will there be fields the user can see but not change? Why or why not? That is business logic. Will there be limits to what certain users can do based on certain conditions? That is business logic.
This does not mean the UI knows about all business logic, of course, many data-moving operations have nothing to do with the UI.
But in the end the question is not how to keep BL out of the UI, you cannot do that, the question is which kinds of BL will be in the UI. That tends to come down to types, ranges of values, allowed operations, and so forth.
So either the UI gets all of that information from a lower tier, or some of it is reproduced in the UI layer.
So, one reason is maintainability. If the client is already distributed everywhere, you don't need to require a re-install or re-download when a simple business rule changes. Simply deploy the change to the back-end and you are all set.
It also lets you do things like hide your database behind your firewall. If all of your business logic is in the front-end, it is likely that you need to expose the database publicly so that the business logic can be executed on the client.
But I fear that "business logic" is an overloaded term. What is "business logic"? The right architecture is the architecture that makes most sense for your application and needs.
As #Ken Smith said, you should certainly avoid business logic in your UI layer. This is for testability, maintainability, designablity, etc. But this does not mean that everything goes to the back end, especially in a RIA app with significant UI rules. In an MVVM app (Silverlight) or Presentation Model app (Flex), you put UI BEHAVIOR in the ViewModel or PresentationModel layer. Then, you put whatever level of business logic makes sense in your Model. That business logic might just be some validation. It might be more. That is dependent upon your architecture.
I am currently working within a custom framework that uses the database to setup a Page Object which contains the information about Module, View, Controller, etc which is used by a Front Controller to handle routing and the like within an MVC (obviously) pattern.
The original reason for handling the pages within the database was because we needed to be able to create new landing pages on the fly from within a admin interface and because we also needed to create onLoad and onUnload events to which other dynamic objects could be attached.
However, after reading this post yesterday, it made me wonder if we shouldn't move this handling out of the database and make it all file structure and code driven like other frameworks so that pages can be tested without having the database be a component.
I am currently looking at whether to scrap the custom framework and go with one of the standard frameworks and extend it (which is what's most likely right now), but I'm wondering whether to extend the framework to handle page requests through database like we are now or if we should simply go with whatever routing / handling mechanism comes with the framework?
Usually I'm pretty lenient on what I will allow to go on in a "toy" application, but I think there are some bad habits that should be avoided no matter what. Databases are powerful tools, with reasonably powerful languages via stored procedures for doing whatever you need to have done... but they really should be used for storing and scaling access to data, and enforcing your low level data consistency rules.
Putting business logic in the data layer was common years ago, but separation of concerns really does help with the maintainability of an application over its lifespan.
Note that there is nothing wrong with using a database to store page templates instead of the file system. The line between the two will blur even further in the future and I have one system that all of the templates are in the database because of problems with the low budget hosting and how dynamically generated content need to be saved. As long as your framework can pull out a template as easily from a file or a field and process them, it isn't going to matter much either way.
On the other hand, the post from yesterday was about generating the UI layer elements directly from the database (at least, that's how I read it) and not an unusual storage location for templates. That is a deep concern for the reasons mentioned... the database becomes locked to web apps, and only web apps.
And on the third hand, never take other people's advice too much to heart if you have a system that works well and is easy to extend. Every use-case is slightly different. If your maintainability isn't suffering and it serves the business need, it is good enough.