I am designing a WCF service that has several functions:
1. ProductDTO GetProduct ( Guid productId )
2. void SetProduct ( ProductDTO product )
3. List<ProductDTO> GetAllProducts()
4. void SetAllProductValues ( int newValue )
These are the operations the Service will support.
I will have a Business Layer (BL) and a Data-Access Layer (DAL).
I will be using LINQ-TO-EF as my ORM to connect to the SQL server tables.
My question is - what exactly should the DAL contain ?
I am asking this question because I have read 2 different books saying different things:
First Approach: the DAL contains only classes needed for data-access layer (if at all). It includes special entities or functions for that.
The EDMX and model file for the LINQ-TO-EF is in a seperate assembly (that is referenced by the BL and the Service Layer).
In this method - the BL contains the actual functions that perform the LINQ queries.
For example : 'GetProduct' will perform the LINQ query to extract data from the DB. So - in this approach - what exactly is supposed to be in the DAL ? Is it empty ?
Second Approach: the DAL contains functions for performing CRUD operations on the DB, meaning - any LINQ-TO-EF queries will be done in the DAL.
So - in this approach - what exactly does the BL do except for maybe some validations ?
Which approach is the correct one and how does that answer my concern of that approach ?
From MSDN:
"All code that is specific to the underlying data source – such as creating a connection to the database, issuing SELECT, INSERT, UPDATE, and DELETE commands, and so on – should be located in the DAL. The presentation layer should not contain any references to such data access code, but should instead make calls into the DAL for any and all data requests. Data Access Layers typically contain methods for accessing the underlying database data. The Northwind database, for example, has Products and Categories tables that record the products for sale and the categories to which they belong. In our DAL we will have methods like:
GetCategories(), which will return information about all of the categories
GetProducts(), which will return information about all of the products
GetProductsByCategoryID(categoryID), which will return all products that belong to a specified category
GetProductByProductID(productID), which will return information about a particular product"
Of course you are always free to choose your own design, but I like to stick with generally accepted practices so my code will likely be acceptable in any shop and understandable to anyone that has to maintain it later...
Related
This is the situation:
Say I have an application in which two entity types exist:
Company
Person
Moreover, Person has a reference to Company via Person.employer, which denotes the company a person is employed at.
In my application I am using repositories to separate the database operations from my business-model related services: I have a PersonRepository.findOne(id) method to retrieve a Person entity and a CompanyRepository.findOne(id) method to retrieve a Company. So far so good.
This is the dilemma:
Now if I make a call to PersonRepository.findOne(id) to fetch a Person entity, I also need to have a fully resolved Company included inline via the Person.employer property – and this is where I am facing the dilemma of having two implementation options that are both suboptimal:
Option A) Redundant queries throughout my repositories but less database round trips:
Within the PersonRepository I can build a query which selects the user and also selects the company in a single query – however, the select expression for the company is difficult and includes some joins in order to assemble the company correctly. The CompanyRepository already contains this logic to select the company and rewriting it in the UserRepository is redundant. Hence, ideally I only want the CompanyRepository to take care of the company selection logic in order to avoid having to code the same query expression redundantly in two repositories.
Option B): Separation of concerns without query-code redundancy but at the price of additional db roundtrips and repo-dependencies:
Within the PersonRepository I could reference the CompanyRepository to take care of fetching the Company object and then I would add this entity to the Person.employer property in the PersonRepository. This way, I kept the logic to query the company encapsulated inside the CompanyRepository by which a clean separation of concerns is achieved. The downside of this is that I make additional round trips to the database as two separate queries are executed by two repositories.
So generally speaking, what is the preferred way to deal with this dilemma?
Also, what is the preferred way to handle this situation in ASP.NET Core and EF Core?
Edit: To avoid opinion based answers I want to stress: I am not looking for a pros and cons of the two options presented above but rather striving for a solution that integrates the good parts of both options – because maybe I am just on the wrong track here with my two listed options. I am also fine with an answer that explains why there is no such integrative solution, so I can sleep better and move on.
In order to retrieve a company by ID you need to read Person's data, and fetch company ID from it. Hence if you would like to keep company-querying logic in a single place, you would end up with two round-trips - one to get company ID (along with whatever other attributes a Person has) and one more to get the company itself.
You could reuse the code that makes a company from DbDataReader, but the person+company query would presumably require joining to "forward" person's companyId to the Company query, so the text of these queries would have to be different.
You could have it both ways (one roundtrip, no repeated queries) if you move querying logic into stored procedures. This way your person_sp would execute company_sp, and return you all the relevant data. If necessary, your C# code would be able to harvest multi-part result set using reader.NextResult(). Now the "hand-off" of the company ID would happen on RDBMS side, eliminating the second round-trip. However, this approach would require maintaining stored procedures on RDBMS side, effectively shipping some repository logic out of your C# code base.
Is there a method to automatically join tables that have primary to foreign relationship rather then designate joining on those values?
The out and out answer is "no" - no RDBMS I know of will allow you to get away with not specifying columns in an ON clause intended to join two tables in a non-cartesian fashion, but it might not matter...
...because typically multi tier applications these days are built with data access libraries that DO take into account the relationships defined in a database. Picking on something like entity framework, if your database exists already, then you can scaffold a context in EF from it, and it will make a set of objects that obey the relationships in the frontend code side of things
Technically, you'll never write an ON clause yourself, because if you say something to EF like:
context.Customers.Find(c => c.id = 1) //this finds a customer
.Orders //this gets all the customer's orders
.Where(o => o.date> DateTIme.UtcNow.AddMonths(-1)); //this filters the orders
You've got all the orders raised by customer id 1 in the last month, without writing a single ON clause yourself... EF has, behind the scenes, written it but in the spirit of your question where there are tables related by relation, we've used a framework that uses that relation to relate the data for the purposes thtat the frontend put it to.. All you have to do is use the data access library that does this, if you have an aversion to writing ON clauses yourself :)
It's a virtual certaintythat there will be some similar ORM/mapping/data access library for your front end language of choice - I just picked on EF in C# because it's what I know. If you're after scouting out what's out there, google for {language of choice} ORM (if you're using an OO language) - you mentioned python,. seems SQLAlchemy is a popular one (but note, SO answers are not for recommending particular softwares)
If you mean can you write a JOIN at query time that doesn't need an ON clause, then no.
There is no way to do this in SQL Server.
I am not sure if you are aware of dbForge; it may help. It recognises joinable tables automatically in following cases:
The database contains information that specifies that the tables are related.
If two columns, one in each table, have the same name and data type.
Forge Studio detects that a search condition (e.g. the WHERE clause) is actually a join condition.
I tried to do a lot of research but I'm more of a db guy - so even the explanation in the MSDN doesn't make any sense to me. Can anyone please explain, and provide some examples on what Include() statement does in the term of SQL query?
Let's say for instance you want to get a list of all your customers:
var customers = context.Customers.ToList();
And let's assume that each Customer object has a reference to its set of Orders, and that each Order has references to LineItems which may also reference a Product.
As you can see, selecting a top-level object with many related entities could result in a query that needs to pull in data from many sources. As a performance measure, Include() allows you to indicate which related entities should be read from the database as part of the same query.
Using the same example, this might bring in all of the related order headers, but none of the other records:
var customersWithOrderDetail = context.Customers.Include("Orders").ToList();
As a final point since you asked for SQL, the first statement without Include() could generate a simple statement:
SELECT * FROM Customers;
The final statement which calls Include("Orders") may look like this:
SELECT *
FROM Customers JOIN Orders ON Customers.Id = Orders.CustomerId;
I just wanted to add that "Include" is part of eager loading. It is described in Entity Framework 6 tutorial by Microsoft. Here is the link:
https://learn.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using-mvc/reading-related-data-with-the-entity-framework-in-an-asp-net-mvc-application
Excerpt from the linked page:
Here are several ways that the Entity Framework can load related data into the navigation properties of an entity:
Lazy loading. When the entity is first read, related data isn't retrieved. However, the first time you attempt to access a navigation property, the data required for that navigation property is automatically retrieved. This results in multiple queries sent to the database — one for the entity itself and one each time that related data for the entity must be retrieved. The DbContext class enables lazy loading by default.
Eager loading. When the entity is read, related data is retrieved along with it. This typically results in a single join query that retrieves all of the data that's needed. You specify eager loading by using the Include method.
Explicit loading. This is similar to lazy loading, except that you explicitly retrieve the related data in code; it doesn't happen automatically when you access a navigation property. You load related data manually by getting the object state manager entry for an entity and calling the Collection.Load method for collections or the Reference.Load method for properties that hold a single entity. (In the following example, if you wanted to load the Administrator navigation property, you'd replace Collection(x => x.Courses) with Reference(x => x.Administrator).) Typically you'd use explicit loading only when you've turned lazy loading off.
Because they don't immediately retrieve the property values, lazy loading and explicit loading are also both known as deferred loading.
Think of it as enforcing Eager-Loading in a scenario where your sub-items would otherwise be lazy-loading.
The Query EF is sending to the database will yield a larger result at first, but on access no follow-up queries will be made when accessing the included items.
On the other hand, without it, EF would execute separte queries later, when you first access the sub-items.
include() method just to include the related entities.
but what happened on sql is based on the relationship between those entities which you are going to include what the data you going to fetch.
your LINQ query decides what type of joins have to use, there could be left outer joins there could be inner join there could be right joins etc...
#Corey Adler
Remember that you should use .Include() and .ThenInclude() only when returning the object (NOT THE QUERYABLE) with the "other table property".
As a result, it should only be used when returning APIs' objects, not in your intra-application.
I'm currently writing my first project using core data, and am having trouble working out how to query the relationship between some of my data.
In sql language, i have a Country table, which joins to a CountryLink M-M table containing the following fields:
countryId1
countryId2
bearing
What would be the correct way to model this in Core Data?
So far i have set up a single Country entity and a CountryLink entity (containing only a bearing field) and have added two 1-to-Many relationships from Country to CountryLink ('CountryLink1' and 'CountryLink2').
I've run the project and looked at the Sqlite db structure produced by Core Data (found here, using this sqlite gui), and the M-M join table seems correct (it contains the bearing, CountryLink1 and CountryLink2 fields), but i'm not sure how i would go about carrying out a fetch request for a single Country NSManagedObject to return an array of related Countries and their bearings?
Any help or related links would be much appreciated.
Thanks, Ted
First a word of warning:
Core Data is not SQL. Entities are not tables. Objects are not rows. Columns are not attributes. Core Data is an object graph management system that may or may not persist the object graph and may or may not use SQL far behind the scenes to do so. Trying to think of Core Data in SQL terms will cause you to completely misunderstand Core Data and result in much grief and wasted time.
See the Tequilla advice
Now, forgetting SQL and thinking in object graphs, your entities would look something like this:
Country{
someAttribute:string // or whatever
countryLinks<-->>CountryLink.country
}
CountryLink{
countryID1:string // or whatever
countryID2:string // or whatever
country<<-->Country.countryLinks
}
As you add Country and CountryLink objects you add them to the relationships as needed. Then to find CountryLink objects related to a specific Country object, you would perform a fetch on the Country entity for Country objects matching some criteria. Once you have that object, you simply ask it for the CountryLink objects in its countryLinks relationship. And your done.
The important thing to remember here is that entities in combination with managedObjects are intended to model real-world objects, conditions or events and the relationship between the same. e.g. a person and his cars. SQL doesn't really model or simulate, it just stores.
This question already has answers here:
What is an ORM, how does it work, and how should I use one? [closed]
(5 answers)
Closed 5 years ago.
As the title says; what is a ORM framework and what is it useful for?
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.
In other words, instead of something like this:
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
you do something like this:
Person p = repository.GetPerson(10);
String name = p.FirstName;
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
Person p = Person.Get(10);
Some also implement complex query systems, so you could do this:
Person p = Person.Get(Person.Properties.Id == 10);
The framework is what makes this code possible.
Now, benefits. First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
From wikipedia:
Object-relational mapping (ORM, O/RM,
and O/R mapping) in computer software
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" that 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.
It's good for abstracting the datastore (flat file / SQL / whatever) out in order to provide an interface that can be used in your code. For example, (in rails) instead of constructing SQL to find the first user in a users table, we could do this:
User.first
Which would return us an instance of our user model, with the attributes of the first user in the users table.
Databases usually work on relational model: you have tables (simplifying: like a spreadsheet), and relations between them - one-to-one, one-to-many, many-to-many, etc, meaning for instance that one record in table A has many related records in table B. You can retrieve data from them as rows (collection of values representing rows from table/tables) More in wikipedia.
Modern programming languages use object model. Objects have methods, attributes (simple or complex) etc.
ORM software does a transition between those models. For instance, it puts all related records from table B into an attribute of object A. This kind of software makes it easier to use relational databases (most popular kind) with object programming languages.
Whenever you go with ORM (Object Relational Mapper) you will find DBAL (Database Abstraction Layer) side by side. So its necessary to know what these are, so as to get good insights of what you are using and whats the advantages that you will get.
DBAL (Database Abstraction Layer)
It acts as a layer between your code and database. Irrespective of whatever your database, the code written will work fine with minor tweaking.
Assume that for the current project your using MySQL once its a fully matured and gets huge traffic your team plan to switch the database to Oracle for some reason then the code you have written in MySQL must be rewritten to Oracle based queries. And rewriting the queries for the whole project is a tedious task.
Instead if you use any DBAL libraries then you can switch the configuration of the database and make sure your project will be up and running within a day (May be with some minor tweaking).
ORM (Object Relational Mapper)
Object Relational Mapping (ORM) is a technique (Design Pattern) of accessing a relational database from an object-oriented language.
If you have used any kind of frameworks like Symfony (if you come from PHP background)/Hibernate (Java), then your familiar with these. Its nothing but Entities.
In order to access the database in Object Oriented context and interface translating the object logic is necessary, this interface is called as ORM. Its make up of the object that give access to data and keep the business rules with themselves.
Eg.
class User{
private $email;
private $password;
public function setEmail($email){
$this->email = $email;
return $this;
}
public function getEmail(){
return $this->email;
}
public function setPassword($password){
$this->password = $password;
return $this;
}
public function getPassword(){
return $this->password;
}
}
/* To save User details you would do something like this */
$userObj = new User();
$userObj->setEmail('sanitizedEmail');
$userObj->setPassword('sanitizedPassword');
$userObj->save();
/* To fetch user details you would do something like this */
$userObj = new User();
$userDetails = $userObj->find($id);
Eg. Doctrine, Propel, RedBean
ORM is:
An abstraction and like any abstraction it makes life easier for you.
From Wikipedia:
http://en.wikipedia.org/wiki/Object-relational_mapping
Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software 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" that 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.
Pros and cons
ORM often reduces the amount of code needed to be written, making the software more robust (the fewer the lines of code in a program, the fewer the errors contained within them).[1].
There are costs as well as benefits for using O/R mapping. For instance, some O/R mapping tools do not perform well during bulk deletions of data. Stored procedures may have better performance but are not portable.
It allows you to do things like this (this is Doctrine code):
$activeUsers = Doctrine::getTable('User')->createQuery('u')->addWhere('u.active = false');
foreach($activeUsers as $user)
{
$user->active = true;
$user->save();
}
Object-relational mapping (ORM) libraries provide this mapping of database tables to domain object classes.