Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I want to know your opinion about using data-aware components in projects. Which are the 'strength' and 'weak' points of developing applications(win32 and web), by using Delphi and data-aware components(from Delphi's standard suite or third-party)?
Using FireBird I've worked a lot with IBObjects, which are a mature suite of components and worked very well.
But there are also a lot of other RDBMS (MySQL, MSSQL, DB2, Oracle, SQLite, Nexus, Paradox, Interbase, FireBird etc). If you have developed big projects, on which you've used a lot data-aware components please answer with the database type and data-aware components suite name.
I'm also interested on DB2 (AS400). What components have you used with success, or which components are really a pain to work with?
I've found that using the data-aware components results in an application with no clear distinction between business and UI logic.
This is fine for small projects but as they grow larger the code becomes less and less maintainable.
All the various bits of event code (and their interactions) can become a real nightmare to understand!
Invariably in such cases I've ditched data-aware components and have switched to a (hand-coded) MVC design.
This does require a lot of up-front coding effort but results (IMHO) in a project that is maintainable, extensible and debuggable.
Having tried both data-aware and non data-aware style of Delphi applications I'm back in the data-aware component camp these days. It takes a bit of work and discipline to correctly layer the code but it's still quicker than doing everything by hand using non data-aware controls.
A few of my tips for data-aware component usage are
Don't just rewrite FishFact on a larger scale. Put some thought into your design.
Don't use a TDataModule, use many TDataModules each responsible for just a small aspect of your applications data.
TDatasets belong on TDataModules, while TDataSources belong on TForms (unless used for master/detail relationships).
Use in-memory datasets such as the DataSnap TClientDataSet.
Your ClientDataSets don't have to mirror your database tables exactly. DataSnap allows you massage your data structures in memory so you can produce datasets tailored for specific purposes. Specifically you can do things like
Joining two or more tables into the one editable dataset
Denormalizing master detail table structures, can simplify your UI code sometimes.
Create in-memory only fields (like calculated fields but you can write to them also)
TClientDataSet nested tables are useful but not the only way to express master detail relationships. Sometimes it's better to do it the old way with two independent TClientDataSets joined through a TDataSource.
Take a look at ORM solutions.
It's a nice approach with multi-tier architecture. See ORM for DELPHI win32
Data aware controls are great, but you have to make sure you get your business code in a separate layer.
That is not difficult, but you need to be aware on how you can do that.
One approach is to have your DataSet components in a DataModule (or other non visual container).
Another handy trick is to use a TClientDataSet to do the UI entry, and use that as an intermediate buffer between the UI and the business layer. The business layer then uses TDataSet components specific to your data layer.
--jeroen
Delphi data-aware components are not depended on the back-end database engine you are using, so using Firebird or MS SQL Server or Oracle or others doesn't matter to your data-aware components. They only know the datasource component assigned to them and do all their DB related stuff via that.
For me, if something can be done with data-aware components in a nice way, I will use them. These are usually small projects which should be done in a short-time. In bigger projects, I might totally rule out data-aware components or use them in forms that are merely used for data presentation and do not receive user input. When it comes to receiving user input, I might use non-data-aware components because I have more flexibility in controlling them and validate the input. Of course data-ware components can be still useful in such scenarios too. You still can validate user input in dataset events like OnBeforePost. Also if you are using a multi-tier design, and your client app represents data presenter layer, your input validation is done in the middle-tier so you can receive input using data-aware components in the client app, and send them to the middle-tier for validation and further processing.
Data-aware components are usful from a RAD and prototyping perspective, especially when you're designing reports or grids that are based on data. i.e. you can tinker at design time.
So I use them like that. But when it comes time to transform it into shipping code, I almost always sever the connections, remove the SQL from the queries, and do everything in code. It's much more predictable and maintainable that way, especially in a multi-developer environment with version control. When the SQL is embedded in the form somewhere, it's a big pain to try to figure out where the SQL actually resides. And it's especially bad to have SQL in two places, and then have to figure out which is in effect.
You can use Unidac which supports many database servers, including Firebird (that i use) and has very nice features.
Coupled with Remobject SDK you will have a nice combination of n-tier architecture and database abstraction.
Related
I would like to write an application based on core data, but I don't know if it's worth, there will be several tables of a few or several thousand data.
What is the situation at the front?
A few thousand records isn't that many in the grand scheme of things, and so is likely to be fine. Though without knowing exactly what you want to do with the data or what platform you're running it on, it's difficult to be sure.
The important thing to remember about Core Data is that it isn't primarily a persistence API i.e. one primarily concerned with getting data onto and off disk like SQL. It is primarily an API for creating the entire model layer for a Model-View-Controller (MVC) design app. As such, it provides a complete data management solution from persistence to object-graph management to integration with the UI.
Core Data is such a comprehensive solution that in Cocoa using bindings, it is possible to create entire apps without writing any custom code.
Any performance you might hypothetically lose in persistence operations with Core Data is almost always overshadowed by the performance gains of the object-graph management and UI integration.
MVC sets up clear distinction between Model, View and Controller.
For the model, now adays, web frameworks provides ability to map the model directly to database entities (ORM), which, IMHO, end up causing performance issues at runtime due to direct database I/O.
The thing is, if that's really the case, why model ORM is so pupular and every web frameworks want to support it either organically or not.
To a web site has huge amount of traffic, it definitely won't work. But what's the work around? Connect directly to database is definitely not a wise solution here.
What's your question?
Is it a good idea to use direct db access from webpages?
A: No.
Is it a good idea to use ORM's?
A: Debatable : See How can I design a Java web application without an ORM and without embedded SQL
Is it a good idea to use MVC model?
A: Yes - it has nothing to do with "Direct" database access - it's about separating your application logic from your model and your display. (Put simply).
And the rationale for not putting database logic inside webpages has nothing to do with performance - it's about security/maintainability etc etc. Calling a usp from a webpage is likely to be MORE performant than using an ORM, but it's bad because the performance gain is negligible, and the cons are significant.
As to workaround: if you mean how do you hook up a database to a web application...?
The simplest way is to use something like Entity Frameworks or Linq-Sql with your Model - there are plenty of examples of this in tutorials on the web.
A better method IMO, is to have a separate Services layer (which may be WCF based), and have all the database access inside that, with DTO's transferring the data to your Web Application which has it's own ViewModel.
Mvc is not about orm but about separation of display logics and business logics. There is no reason your exposed model needs to be identical to you database model and many reasons to ensure that the exposed model closely matches what is to be displayed.
The other part of the solution to scale well would be to implement caching in the control and be able to distribute load on sevaral instances.
I think #BonyT has given a good answer, (and I've voted for it :) ), I'd just add that:
"web frameworks provide the ability to map the model directly to database entities (ORM), which, IMHO, ends up causing performance issues at runtime due to direct database I/O"
Even if this is true, using an ORM can solve a lot of problems with a model being easy to update and translate back and forth between a database. Solving a performance hit by buying extra web servers or cloud instances is much cheaper than having to buy extra developers or extra hours in development to solve things other people have already written ORMs to do for you.
I've found no clear answer so far, but maybe I've searched the wrong way.
My Question is, can Core Data to be used as a Persitence Storage for a Server Project? Where are Core Data's Limits, how much Data can be handled with Core Data and SQLite? SQLite should handle a lot of Data very well according to their website. I know of a properitary Java Persitence Manager with an Oracle DB as Storage that handles Millions of Entries and 3000 Clients without Problems. For my own Project I wonder if I can use Core Data on the Server Side for User Mangament and intern microblogging, texting with up to 5000 clients. Will it handle such big amounts of Data or do I have to manage something like that myself? Does anyone happend to have experience with huge amounts if Data and Core Data?
Thank you
twickl
I wouldn't advise using Core Data for a server side project. Core Data was designed to handle the data of individual, object-oriented applications therefore it lacks many of the common features of dedicated server software such as easily handling multiple simultaneous accesses.
Really, the only circumstance where I would advise using it is when the server side logic is very complex and the number of users small. For example, if you wanted to write an in house web app and have almost all the logic on the server, then Core Data might serve well.
Apple used to have WebObjects which was a package to manage servers using an object-oriented DB much like Core Data. (Core Data was inspired by a component of WebObjects called Enterprise Objects.) However, IIRC Apple no longer supports WebObjects for external use.
Your better off using one of the many dedicated server packages out there than trying to roll your own.
I have no experience using Core Data in the manner you describe, but my understanding of the architecture leads me to believe that it could be used, depending on how you plan to query and manipulate the data.
Core Data is very good at maintaining an object graph and using faults to bring parts into memory as needed. In that manner, it could be good on a server for reducing memory requirements even with a large data set.
Core Data is not very good at manipulating collections of objects without loading them into memory, making a change, and writing them back out to disk. Brent Simmons wrote a blog post about this, where he decide to stop using Core Data for some of his RSS reader's model objects because an operation like "mark all as read" didn't scale. While you would like to be able to say something like UPDATE articles SET status = 'read', Core Data must load each article, set its status property, then write it back to disk.
This isn't because Apple engineers are stupid, but because the query layer can't make assumptions about the storage layer (you could be using XML instead of SQLite) and it also must take into account cascading changes and the fact that some article objects may already be loaded into memory and will need to be updated there.
Note that you can also write your own storage providers for Core Data, see Aaron Hillegass's BNRPersistence project. So if Core Data was "mostly good" you might be able to improve on it for your application.
So, a possible answer to your question is that Core Data may be appropriate to your application, as long as you do not need to rely on batch updates to large number of objects. In general, no algorithm or data structure is appropriate for every scenario. Engineering is about wisely choosing between trade-offs. You won't find anything that works well for many clients in every case. It always matters what you are doing.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I know how that question looks, but I'm quite serious. I am trying to create an application that will help me in learning databases (sql, queries, proper database design, etc). I'm using a pet project at work so I have something to focus on with actual requirements. The original project was written ("Frankensteined together", as the original author said) via MS Access. I'd like to learn how to do it better via SQLite, but don't know how to recreate the other functionality Access provided.
Using this site as a way to interact with programmers and developers (I don't work with any), I've thus far read all of Database Design for Mere Mortals as recommended in this question. So, I've got a nice little database design that I plan to implement using SQLite.
I also checked out how to design a user interface for the app via using Balsamiq's Mockups, and submitted some ideas to my potential user base (my peers on my team) to have them give feedback.
Database --> <insert code here> --> User Interface
However, the part that falls down for me is how to I bridge the gap between the two designs? I realize that's obviously where coding comes in, but to date I haven't made anything with a GUI. Searching around, I didn't seem to find anything as definitive to assist me (a book, a website, even a process to follow) in trying to actually write the app.
I know Perl to some degree, but have only used it for command-line apps; I could use the Win32::GUI module, but I don't really understand the differences between GUI programming and command-line programming, other than to just know that they are different.
Is there a model or a guide to follow regarding GUI development? Are there specific resources for tying an application to a database?
The general pattern that is followed nowadays is:
Database -> DAL -> BLL -> Controller -> View Model -> UI
Where
DAL == Data Access Layer (aka ORM, Object-Relational mapper)
BLL == Business Logic Layer
Googling each of these terms should give you a fairly good idea of where to get started. Note that you don't always need every layer. The BLL and View Model, for example, can be optional if the app is small enough.
See also Model View Controller (MVC) for web development, and Model View Presenter (MVP) or Model View ViewModel (MVVM) for desktop development.
Although the NerdDinner tutorial is Microsoft/Web specific, it contains all of these concepts in one place.
Middleware is another term that you may see thrown around for what you are describing.
The database itself can be a combination of a few different points:
Stored procedures - This would be used instead of directly accessing tables and provides a layer of abstraction.
Tables or views - Directly accessing column names that can be useful if you are building a lightweight app.
Combination of the two. Some tables could be directly accessed while other database activity is done through stored procedures.
The UI can be just a presentation layer or can have a couple of other layers tied to it as one could use a combination of ASP.Net's layers including C#, HTML, and JavaScript for creating web applications.
I've been reading through a couple of questions on here and various articles on MVC and can see how it can even be applied to GUI event intensive applications like a paint app.
Can anyone cite a situation where MVC might be a bad thing and its use ill-advised?
EDIT: I'm specifically talking about GUI applications here!
I tried MVC in my network kernel driver. The patch was rejected.
I think you're looking at it kind of backwards. The point is not to see where you can apply a pattern like MVC, the point is to learn the patterns and recognize when the problem you are trying to solve can naturally be solved by applying the pattern. So if your problem space can be naturally divided into model, view and controller then it is a good candidate for MVC. If you can't easily see which parts of your design fall into the three categories, it may not be the appropriate pattern.
MVC makes sense for web applications.
In web applications, you process some data (on SA: writing questions, adding comments, changing user info), you have state (logged in user), you don't have many different pages, but a lot of different content to fit into those pages. One Question page vs. a million questions.
For making CMS, for example, MVC is useless. You don't have any models, no controllers, just a pages of text with decorations and menus. The problem is no longer processing data - the problem now is serving that text content properly.
Tho, CMS Admin would build on top of MVC just fine, it's just user part that wouldn't.
For web services, you'd better use REST which, I believe, is a distinct paradigm.
WebDAV application wouldn't benefit greatly from MVC, either.
The caveat on Ruby for Web programming is that Rails is better suited for building Web applications. I’ve seen many projects attempt to create a WebDAV server or a content management system CMS with Rails and fail miserably. While you can do a CMS in Rails, there are much more efficient technologies for the task, such as Drupal and Django. In fact, I’d say if you’re looking at a Java Portal development effort, you should evaluate Drupal and Django for the task instead.
Anything where you want to drop in 3rd party components will make it tough to work in the MVC pattern. A good example of this is a CMS.
Each component you get will have their "own" controller objects and you won't be able to share "control" of model -> ui passing.
I don't necessarily know that MVC is ever really a bad idea for a GUI app. But there are alternatives that are arguably better (and also arguably worse depending on whose opinion you're asking). The most common is MVP. See here for an explanation: Everything You Wanted To Know About MVC and MVP But Were Afraid To Ask.
Although I suppose it might be a bad idea to use MVC if you're using a framework or otherwise interacting with software that wasn't designed with MVC in mind.
In other words, it's a lot like comparing programming languages. There's usually not many tasks that one can say that one is better than the other for. It usually boils down to programmer preference, availability of libraries, and the team's experience.
MVC shouldn't be used in applications where performance is critical. I don't know if this still applys with the increase of computing power but one example is a call center application. If you can save .5 seconds per call entering and updating information those savings add up over time. To get the last bit of performance out of your app you should use a desktop app instead of a web app and have it talk directly to the database.
When is it a bad thing? Where ever there is another code-structure that would better fit your project.
There's countless projects where MVC wouldn't "fit", but I don't see how a list of them would be of any benefit..
If MVC fits, use it, if not, use something else..
MVC and ORM are a joke....they are only appropriate when your app is not a database app, or when you want to keep the app database agnostic. If you're using an RDBMS that supports stored procedures, then that's the only way to go. Stored procs are the preferred approach for experienced application developers. MVC and ORM are only promoted by companies trying to sell products or services related to those technologies (e.g. Microsoft trying to sell VS). Stop wasting your time learning Java and C#, focus instead on what really matters, Javascript and SQL.