I see it used a lot in context of data. From ScottGu's post:
One of the really powerful
capabilities provided by LINQ and
query syntax is the ability for you to
define new classes that are separate
from the data being queried, and to
then use them to control the shape and
structure of the data being returned
by the query.
What does he mean when he refers to shape of the data?
I think these are informal terms, and the definitions are subjective. I would use "shape" to refer to how the object fits in with other objects in the system. (Compare "surface area", which is a rough (no pun intended :-) measure of the complexity of the object's interface.) I'd use "structure" to refer to how the object is designed and implemented internally.
Hence you can have classes that have a good "shape", but a structure like crepe paper. That's probably easier to refactor than the other way around: a poor shape, but good implementation. (I'm sure some folks would question whether the latter is even possible.)
consider shape to be the objects "api" while the structure is it's internal implementation. In a well designed system the shape will remain static while the structure may change significantly.
The shape is any spatial attributes (especially as defined by outline) of the object, whereas the structure is the manner of construction of the object and the arrangement of its parts. Of course, that can apply to any type of object. :)
Generally, I would consider the shape of an a class to be the public methods and properties that the class offers. The structure would be the internal constructs and representation used. In the context of the quoted material, I would take it to mean that by allowing one to define the return type of a query using anonymous or alternate named classes, you can redefine the data returned by query, constraining and transforming its shape from the original data source.
For example, say you have a user table that is related to a contacts table. Using LINQ and anonymous class as the selection, you can return a user with primary contact object without having to define a particular view; using only LINQ.
var userWithContact = from u in db.Users
select new
{
Name = u.Name,
Address = u.Contacts
.Where( c => c.Type = "self" ).First().Address
};
Related
Both Filter and Interpreter Design Patterns look like much similar task oriented. Filter does filtering a list for some criteria, while Interpreter is doing pretty much same for a single element.
But I wonder why Filter is Structural and Interpreter is behavioral. Anyone got an idea?
Although it is true that they are "task-oriented", these two patterns actually refer to different purposes, let's take the example of an SQLTable class.
Filter pattern can serve to filter/remove/hide, more generally affect the structure of your database but don't modify its behavior at all.
Example 1 : Once filtered, it's only a new SQLTable with less/more rows and maybe less/more columns
Interpreter pattern belongs to behavioral pattern, in the sense that it modifes the behavior of an object (often represented with the help of a structural pattern such as Composite). The difference lies in the interpretation of the structure to behave differently.
Example 2: Once interpreted as a csv-table, your SQLTable can now be exported to a PDF file
I guess your misunderstanding comes from the fact that they are both applied to a structure in order to create something else but the actual difference lies in their intent rather than their concrete implementation which are relatively close in practice
I'm working with threedimensional arrays and it would be neat if I could name the array dimensions. The question marks in the example below are giving me the idea that this is possible.
Is it, and if so, how does it work? I can't seem to find it anywhere.
The three question marks are showing you that this array has three dimensions. If there was only one question mark, it would mean that the variable was declared as one dimensional. This is built in to VB and can't be change, as far as I know.
I think there's real value into making your code more readable and self-documenting. If I had a three dim array, I would probably create some custom class modules to model the objects that I was using.
If your first dimension is a SchoolID, your second dimension is a ClassID, and your third dimension is a StudentID, then code using custom class modules like this
Debug.Print Schools(10).Classes(3).Students(7).Name
is more readable than
Debug.Print arrLeeftijdenG5(10,3,7)
I don't know what you're storing, so it's just an example. Consider using custom class module to model the real-world objects your code is manipulating. There's a bit more set up involved, but it pays dividends down the road.
Fortran 2003 supports data polymorphism by using class, like:
subroutine excute(A)
class(*) :: A
select type (A)
class is ()
...
type is ()
...
end select
end subroutine
My question is: if I need to call this subroutine a huge amount of times, whether it will slow the code down because of the SELECT statement?
SELECT TYPE is typically implemented by the descriptor for the polymorphic object (CLASS(*) :: A here) having a token or pointer or index of similar that designates the dynamic type of the object. Execution of the select type is then like a SELECT CASE on this token, with the additional complication that non-polymorphic type guards (TYPE IS) are matched in preference to polymorphic guards (CLASS IS).
There is some overhead associated with this construct. That overhead is more than if the code did nothing at all. Then again, code that does nothing at all is rarely useful. So the real question is whether the use of SELECT TYPE is better or worse execution speed wise to some alternative approach that provides the necessary level of functionality (which might be less than the full functionality that SELECT TYPE provides) that your code needs. To answer that, you would need to define and implement that approach, and then measure the difference in speed in a context that's relevant to your use case.
As indicated in the comments, an unlimited polymorphic entity is essentially a type safe way of storing something of any type. In this case, SELECT TYPE is required at some stage to be able to access the value of the stored thing. However, this is only a rather specific subset of F2003's support for polymorphism. In more typical examples SELECT TYPE would not be used at all - the behaviour associated with the dynamic type of an object would be accessed by calling overridden bindings of the declared type.
Can anyone confirm whether or not the SQL:1999 Array type Constructor provides any operations for searching the Array in a WHERE clause?.
As an Example If a table EMPLOYEES had a column
QUALIFICATION VARCHAR(20) ARRAY[10]
containing values such as ARRAY['BSC','MBA']
Does the standard support some way of querying EMPLOYEES to find all Employees with an MBA?
Well, you can always use an element reference (ISO/IEC 9075-2:1999, 6.13 ):
WHERE QUALIFICATION(1) = 'BSC'
OR QUALIFICATION(2) = 'BSC'
...
Of course, the problem is that you need to write a comparison for each possible position.
I am not aware of any operators that allows you to compare a scalar with an array, although I would suppose a DBMS that has native support for ARRAY types ould let you create a function that does the job.
I must say I never had the need for array types - I would typically build a one-to-many detail table, or in rare cases, add multiple columns (yeah - a repeating group. send the relational police to hunt me if you like :)
Would you care to explain why you need to know this, or what problem you are trying to solve with an ARRAY?
(sorry for my English)
For example, in my DAL,I have an AuthorDB object, that has a Name
and a BookDB object, that has a Title and an IdAuthor.
Now, if I want to show all the books with their corresponding author's name, I have to get a collection of all the Books, and for each of them, with the IdAuthor attribute, find the Author's name. This makes a lot of queries to the database, and obviously, a simple JOIN could be used.
What are my options? Creating a 'custom' object that contains the author's name and the title of the book? If so, the maintenance could become awful.
So, what are the options?
Thank you!
Don't write something buggy, inefficient, and specialized ... when reliable, efficient, and generic tools are available. For free.
Pick an ORM. NHibernate, ActiveRecord, SubSonic, NPersist, LinqToEF, LinqToSQL, LLBLGenPro, DB4O, CSLA, etc.
You can create a View in the database that has the join built into it and bind an an object to that, e.g. AuthorBooksDB. It doesn't create too bad a maintenance headache since the view can hide any underlying changes and remains static.
If you can separate the database query from the object building, then you could create a query to get the data you need. Then pass that data to your builder and let it return your books.
With Linq to SQL, that can be done as easily as:
public IEnumerable<Book> AllBooks()
{
return from book in db.Books
join author in db.Authors on book.AuthorId equals author.Id
select new Book()
{
Title = book.Title,
Author = author.Name,
};
}
The same can be achieved with DataTables / DataSets:
public IEnumerable<Book> AllBooks()
{
DataTable booksAndAuthors = QueryAllBooksAndAuthors(); // encapsulates the sql query
foreach (DataRow row in booksAndAuthors.Rows)
{
Book book = new Book();
book.Title = row["Title"];
book.Author = row["AuthorName"];
yield return book;
}
}
Thank you very much for your inputs.
Actually, we are trying to keep the database objects as close as possible to the actual columns of the corresponding table in the database. That's why we cannot really add a (string) 'Author' attribute to the BookDB object.
Here is the problem I see with using 'View' objects. In the database, if the schema has to be modified for any reason (e.g: In the Book table, the 'Title' column has to be modified for 'The_Title', how do we easily know all the 'View' objects that have to be modified? In other words, how to I know what objects have to be modified when they make queries that use multiple joins?
Here, since we have a AuthorsBooks object, we can see by the name that it probably makes a query to the book and author tables. However, with objects that make 4 or 5 joins between tables we cannot rely on the object name.
Any ideas? (Thank you again, this is a great site!)
I suggest you take a look at Domain Driven Design. In DDD, you get all business objects from a repository. The repository hides your data store and implementation, and will solve your problems on how to query data and keeping track of database changes. Because every business object is retrieved from the repository, the repository will be your single point of change. The repository can then query your database in any way you find efficient, and then build your domain objects from that data:
var books = new BookRepository().GetAllBooks();
You should be able to code the repositories with any of the technologies mentioned by Justice.