Say that I have a program with the following architecture:
GUI: The graphic user interface which let the user interact with the program
Control: the "logic" of the program and the middle man between the GUI layer and the wrapper-layer.
DatabaseWrapper: The layer which handles connections to the database and retrieves data as result sets which are then returned to the Control layer as data structures that are not specifically related to databases, such as arrays and Strings.
Database: The database outside the program.
Does this particular architecture has a name? I presume it is MVC (Model–View–Controller) where Model is Database, View is GUI and Controller is Control? However, this either leaves out the Database or else 'model' of MVC is in this case simply composed of both Database and DatabaseWrapper? So maybe there is another more adequate name for the above architecture? Any help much appreciated. It is for a school project.
What you describe is a form of a three tier layered architecture where you separated the data access layer (Database Wrapper) from the data store (database).
Check this article from msdn or the obligatory wikipedia article. Look at this image from another article:
Related
First of all I'm new to Entity Framework and have inherited a vb.net project. I'm trying to add an existing table to the model. The table is in the same database the model refers to.
I've read and watched lots and theoretically understand what I need to do but everyone speaks about right clicking on the emdx file and click on 'Update Model from Database'. This project doesn't have an emdx file. (hidden or otherwise)
So I'm confused. So I have one?
If not can anyone advise me on another way to update the model to add an already existing table please?
Thanks
I've read and watched lots and theoretically understand what I need to do but everyone speaks about right clicking on the emdx file and click on 'Update Model from Database'
That's just one approach to EF: "database first" where the database is designed and then the EF Model (in the form of a .edmx file) is part of the project (and then used to generate the code files for db context and entity types).
The other two approaches are "Model First" where the designer (or direct XML editing) is used to write the .edmx directly.
Finally – and this is what you might have – there is "Code First" where the DbContext derived type and entity types are written directly. Check the DbContext derived type and the entity types being hand written (or at least maintained).
For information on the different approaches the EF's documentation site includes introductory articles including a video about the different models.
I have a dataset table with various columns that are created during form load.
These columns are currently either system.double or system.string types.
And it is displayed in a datagridview.
This works fine.
But I need another column that can store a "list" or some collection in the data table.
A list of strings would do but a custom class would be better.
How is this usually done?
I have spent literally weeks googling this and I dont know where to start. The more I have looked the more confused I have ended up. I end up with more questions than answers, like how is it displayed in the datagridview? I read about a combo box?
I hope someone can give me some pointers in how to get this achieved. I've not posted any code as I think its more the theory of this I need help with.
What you are asking for has does have multiple concerns for most programmers. The storage of data (#1) and the displaying of said data to the user (#2)
For #1 I recommend the .net entity framework. It gives support for storing, querying and updating classes for use in the database. Through most tutorials that I have found it is possible to model the structure of the database tables and their relations and then build a database around that model OR to use an existing database and create entities (entity framework's class objects) around the existing structures and relationships.
Here is a link to a very good beginner tutorial that I have used before: CodeProject Entity Framework Tutorial for Absolute Beginners
For #2 I can recommend the Windows Presentation Foundation. It has lots of bells and whistles to make using a data source and displaying the relevant dependent data very easily through its unique method of data binding. From the tutorials I have used on PluralSight it can be as easy as dragging and dropping from an imported data source like the entity framework database. Alternatively, one can just handle selected row changes for one data grid and then show the dependent data in another data grid.
My team is writing a large scale business website in ASP.NET MVC 4 using the database-first approach. Does anyone know if it's possible to have data annotations automatically generated based on the database schema? It seems redundant to have to manually write the "buddy" metadata classes containing the data annotations when the framework should be aware of a database column's properties and make these part of the POCO classes it generates. Any suggestions would be greatly appreciated!
Take a look at LINQ to SQL.
You can use it to create a .dbml file in a graphical editor by dragging the tables from the server explorer.
Here's the MSDN How to: Create LINQ to SQL Classes in a Web Project
1) The framework does a good job of extrapolating data annotation based on table structure, but they won't be perfect.
2) Sadly, when you reach a point when you want to customize more than the framework, you are stuck with Buddy classes. They're a bit tedious but so far the best method I've found for customizing data annotation.
3) All too often, I find myself gravitating toward custom classes and away from generated POCO's. The reason is usually the differences between storing and displaying. In entry screens
I will often break up phone #'s into 3 textboxes.
Lookups for foreign keys require select lists (often added to model).
Often I'll pass other values that may be relevant to my View functionality but not specific to the storage table (display fields, navigation / bread crumbs)
Use the Database First approach with the Entity Framework.
You can generate the entity model from an existing database using the entity data model wizard.
See http://msdn.microsoft.com/en-us/data/jj206878
#Kerezo covers pretty much exactly what you want to do here: Add Data Annotation To Entity Framework(Or Linq to SQL) generated class
It is not possible to auto generate the data annotations automatically.
I'm designing a C# application
Presentation ( web site + flex apps )
Business Logical Layer (might be WCF to enable multi client platforms)
Data Access Layer ( With NHibernate )
We're going to integrate our solution in many preexistant client's database environnements and we would like to use NHibernate in the DAL.. My colleague pointed out that generating classes from client's DB (like User or Image) with NHibernate would cause the BLL to blow up in our face at each DB changes !
So the question is how do we prevent that from happening ?
We're thinking about creating business objects and map NHibernate objects to these BO (hum, does that make them DTOs ?) with AutoMapper and prevent dal changes from affecting BLL.. Is this the way to go ?
Thanks !
EDIT :
To give a better understanding of what we're trying to achieve, you might need context :
We're building a photo storing/sharing app in Flex for the front-end and C# on the back-end mainly for our company, so we handle every aspects of the code and DB.
But : that product can also be bought by tiers, which eventually have already a database with User table or Image table. I'm thinking here about a new prospect who have an Image table with a few hundred millions of rows and adding columns for our business logic isn't going to be happening because of a too long ALTERing of the table.
Even though it would be possible (User table for example can be modified because of lesser rows), we're asking ourselves how to handle table structure changes without impacting all of our solution each time we have to integrate in a tier database, from BLL to client app in Flex !
in my experience, your business objects (AKA Domain Objects) should be modelled in OO to represent your real life business entities and your tables in 3rd normal form (this may change depending on what design you are after speed vs file size)
NHibernate should map between your BO's and Tables, using its mapping files.
now you have legitimate cases:
You need to add/remove a column, we decided to remove addressline4, this will echo a change in your Address Object, thats fine.
You move a column to a better place, our Client object contains notes, which is currently stored in the Contract_Extra table, which is going to be moved into the Client table. moving the column into a better place will only effect the Mapping file, in this case
I doubt there is a blanket reasoning, however I hope the examples make you think about this
I have not tried NH accross multiple Db's, also should each database have its own service on top?
here are some links
Multi table entites
PoEAA <- look at the Single Table inheritance, Class table inheritance and the other one
Hope this helps
It sounds like you want to design your domain model to be database agnostic. I too am interested in the best approach to having a central domain model that can map over to multiple different database models.
The way you are proposing, to create DTO's from each database using code generators, could be an option. Another would be to create custom NHibernate mappings for each preexisting database. You still may need to use some DTOs to make some of the mappings less difficult but it may give you more control.
These are just some thoughts. More experienced users with NHibernate probably will have better insight to your situation.
I am actually stuck in 3-tier structure. I surfed the internet and found two terminologies "Database Abstraction Layer" & "Data Access Layer".
What are the differences between the two?
Data Access Layer= Create, Read, Update, Delete (CRUD) operations specific to your application domain
Data Abstraction Layer= performs generic database operations like connections, commands, parameters insulating you from vendor specific data libraries and providing one high level api for accessing data regardless of whether you use MySQL, Microsoft SQL Server, Oracle, DB2, etc...
My understanding is that a data access layer does not actually abstract the database, but rather makes database operations and query building easier.
For example, data access layers usually have APIs very similar to SQL syntax that still require knowledge of the database's structure in order to write:
$Users->select('name,email,datejoined')->where('rank > 0')->limit(10);
Data abstraction layers are usually full blown ORM's (Object-Relational Mappers) that theoretically prevent the need to understand any underlying database structure or have any knowledge of SQL. The syntax might be something like this:
Factory::find('Users', 10)->filter('rank > 0');
And all the objects might be fully populated with all the fields, possibly joined with any parent or child objects if you set it that way.
However, this abstraction comes with a price. I personally find ORM's like doctrine or propel to be unnecessary and inefficient. In most cases a simple data access layer will do fine, with manual SQL for anything that requires special attention, instead of having to destroy your application's performance for some syntactic sugar. This area is a pretty heated debate so I won't go into it anymore.
If you meant database abstraction layer, then it would be something along the lines of PDO, so that your code can be used for a larger number of database vendors. PDO works with MySQL, PostgreSQL, and mysqli among others, I believe.
From Wiki:
Data Access Layer
A data access layer (DAL) in computer software, is a layer of a
computer program which provides simplified access to data stored in
persistent storage of some kind, such as an entity-relational
database.
For example, the DAL might return a reference to an object (in terms
of object-oriented programming) complete with its attributes instead
of a row of fields from a database table. This allows the client (or
user) modules to be created with a higher level of abstraction. This
kind of model could be implemented by creating a class of data access
methods that directly reference a corresponding set of database stored
procedures. Another implementation could potentially retrieve or write
records to or from a file system. The DAL hides this complexity of the
underlying data store from the external world.
For example, instead of using commands such as insert, delete, and
update to access a specific table in a database, a class and a few
stored procedures could be created in the database. The procedures
would be called from a method inside the class, which would return an
object containing the requested values. Or, the insert, delete and
update commands could be executed within simple functions like
registeruser or loginuser stored within the data access layer.
In short, your basic CRUD functionalities/logics on business objects to push to/pull from Persistance/Storage layer falls here. For most cases you might want just this. ORM mapping, interfaces of business objects of Model etc fall here.
Database Abstraction Layer
A database abstraction layer is an application programming interface
which unifies the communication between a computer application and
databases such as SQL Server, DB2, MySQL, PostgreSQL, Oracle or
SQLite. Traditionally, all database vendors provide their own
interface tailored to their products which leaves it to the
application programmer to implement code for all database interfaces
he or she would like to support. Database abstraction layers reduce
the amount of work by providing a consistent API to the developer and
hide the database specifics behind this interface as much as possible.
There exist many abstraction layers with different interfaces in
numerous programming languages.
Basically, its an additional layer of abstraction so that you CRUD against vendor independent interfaces and worry less about implementation details of various database vendors. You will need this only if you would want to support more than one database. ORMs, Micro ORMs, wrappers, generic driver classes, whatever the name is, etc that deals with connection establishment, parameter handling, execution etc fall here. It's just an additional layer just before Persistance/Storage layer. In 3 tier terminology, both these layers fall under one as they are not logically separate.
To summarize, DAL is about data, DbAL is about database. DAL defines operations, DbAL operates. DAL sits behind DbAL which is just behind actual Db. DAL calls DbAL. DAL is a good thing to separate business logics (in Model) from CRUD logics, while DbAL is seldom needed (but I love it). DAL is more high level design mapping, DbAL is more low level architecture and implementation. Both separates responsibilities. ORMs are massive structures that does both for you. I'm not sure how you separate them when using ORMs. You need not since ORMs handle all that for you. Ideally, I would anyway have DAL in one project, and DbAL in another which I would simply call Persistence layer since there is no point in separating Db and operations on it.