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.
Related
I want to ask this because I want to know developer perspective about developing from scratch mobile games.
Let's say the project is already going to start its development.
I am already aware of the specification of the project example.
Logic, Browser/devices to support, IDE to be used.
What should be the first thing to do.
Create the UI/UX designs for all devices with no functionality
and after the designs are finalized then integrate functionality
Create functionality logic then do design
Do design and functionality together
which of these will save much more time.
please share your experiences about this development and how to make out of it
so that failure of delivering the project will be at its minimum errors
Every of these aproaches may work, however I will tell you about my experience.
I did a lot of different projects using points you provide in the question, but for me the easiest and most successful approach was logic first, design second.
How to start using this approach?
Think about use case at first. For example, user should be able to register in the game.
Implement database structure(if needed). For example, create table 'Users'.
Implement data access logic. For example, write code that saves a username and a password.
Create service layer with use case's (business) logic implementation . For example, you can write saveUser method.
Create a simple(ugly) UI that allows you to feel the use case and to test it.
Pay guru designer to create clean design. For example, a design of the registration page.
Сontinue with step 1.
Advantages?
Allows to create really working MVP with ease.
UI manipulates only real and dynamic data.
Allows you to build foundation first.
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.
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.
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 7 years ago.
Improve this question
What are some best practices to keep in mind when developing a script program that could be integrated with a GUI, probably by somebody else, in the future?
Possible scenario:
I develop a fancy python CLI program that scrapes every unicorn images from the web
I decide to publish it on github
A unicorn fan programmer decides to take the sources and build a GUI on them
he/she gives up because my code is not reusable
How to prevent the step four letting the unicorn fan programmer build his/her GUI without too much hassle?
You do it by applying a good portion of layering (maybe implementing the MVP pattern) and treating your CLI as a UI in it's own right.
UPDATE
This text from the wikipedia article about the Model-View-Presenter pattern explains it quite well.
Model-view-presenter (MVP) is a user
interface design pattern engineered to
facilitate automated unit testing and
improve the separation of concerns in
presentation logic.
The model is an interface defining the data to be displayed or
otherwise acted upon in the user
interface.
The view is an interface that displays data (the model) and routes
user commands (events) to the
presenter to act upon that data.
The presenter acts upon the model and the view. It retrieves data
from repositories (the model),
persists it, and formats it for
display in the view.
The main point being that you need to work on separation of concern in your application.
Your CLI would be one implementation of a view, whereas the unicorn fan would implement another view for a rich client. The unicorn fan, would base his view on the same presenters as your CLI. If those presenters are not sufficient for his rich client he could easily add more, because each presenter is based on data from the model. The model, in turn, is where all the core logic of your application is based. Designing a good model is an entire subject in itself. You may be interested in reading, for example, about Domain-Driven Design, even though I don't know how well it applies to your current application. But it's interesting reading anyway.
As you can see, the wikipedia article on MVP also talks about testability, which is also crucial if you want to provide a robust framework for others to build on. To reach a high level of testability in your code-base, it is often a good idea to use some kind of Dependency Injection framework.
I hope this gives you a general idea of the techniques you need to employ, although I understand that it may be a little overwhelming. Don't hesitate to ask if you have any further doubts.
/Klaus
This sounds like a question about how to write usable code.
When considering reusablility of code, generally speaking, one should try to:
separate functionality into modules
have a well-defined interface
Separating functionality into modules
One should try to separate code into parts that have a simple responsibility. For example, a program that goes out to the internet to scrape pictures of unicorns may be separated into sections that a) scrapes the web for images, b) determines if an image is a unicorn and c) stores the said unicorn images into some specified location.
Have a well-defined interface
Having a well-designed interface, an API (application programming interface), is going to be crucial to providing a way to reuse or extend an application.
Providing entry points into each functionality will allow other programmers to actually write a new user interface for the provided functionality.
The solution to this kind of problem is very simple, but in practice, a lot of junior programmers have trouble with this pattern. Here's the solution:
You design a unicorn-scraping API. This is the hard step; good API design is insanely hard, and there aren't many examples to study. One API that I think is worth studying is the one in Dave Hanson's book C Interfaces and Implementations.
Then you design your command-line interface. If the functionality you are exposing is not to complicated, this is not too hard. But if it's complicated, you may want to think seriously about managing your API using an embedded scripting language like Lua or Tcl and designing an interface for scripting rather than for the command line.
Finally you write your command-line processing code and glue everything together.
Your hypothetical successor builds his or her GUI in one of two ways: using the embedded scripting languages, or directly on top of your API.
As noted in other answers, model/view/controller may be a good pattern to use in designing your API.
You'll be taking input, executing an action, and presenting output. It might be a good idea to use a callback mechanism (such as event handlers, passing a method as a parameter, or passing this/self to the called class) to decouple the input and output methods from the execution of the action.
Aside from this, program to an interface, not to an implementation - the essence of MVC/MVP, as klausbyskov mentioned. e.g., Don't directly call file.write(); make myModel.saveMyData() which calls file.write, so someone else can make a somebodysModel.saveMyData() that writes to a database.
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.