Security Application Block Dependencies of Enterprise Library
- Core library functionality. The Enterprise Library Core provides services, such as instrumentation and configuration, and is a shared dependency of all Enterprise Library application blocks. The core library functionality is contained in the assembly Microsoft.Practices.EnterpriseLibrary.Common.dll.
- The ObjectBuilder subsystem. The ObjectBuilder subsystem performs all of the repetitive and necessary tasks for creating and disposing of object instances, while still providing a high level of flexibility. Enterprise Library uses the ObjectBuilder subsystem for tasks such as injecting configuration into block classes and connecting instrumentation classes to application blocks. The ObjectBuilder subsystem is contained in the assembly Microsoft.Practices.ObjectBuilder.dll.Depending on the specific functionality you require from the Security Application Block, you may also require the following application block contained in the Enterprise Library:
- The Caching Application Block. The Security Application Block uses the Caching Application Block to cache security information and then retrieve it when required. You can replace the Caching Application Block with your own caching provider. Depending on how you configure the Caching Application Block, you may also require the Data Access Application Block. For more information, see the Caching Application Block documentation.
Security Application Block Documentation
Together with the introduction, the documentation contains the following topics:- Design of the Security Application Block. This topic explains the decisions that went into designing the application block and the rationale behind those decisions.
- Developing Applications with the Security Application Block. This topic explains how to download and install the application block so you can use it in your applications. It also is divided into several subsections. The first subsection, Entering Configuration Information, demonstrates how to configure the application block to perform common tasks. The next subsection, Key Scenarios, demonstrates how to use the application block to perform the most typical security operations.
- Extending and Modifying the Security Application Block. This topic explains how to extend the application block by creating your own providers and how to modify the source code.
- Deployment and Operations. This topic explains how to deploy and update the application block's assemblies and also contains information about configuration.
- QuickStarts. This topic explains how to install and configure the QuickStart applications and contains a series of walkthroughs that demonstrate how to incorporate common security operations into an application.
do you know the Self-Tracking Entities in the Entity Framework
Self-Tracking Entities
Self-tracking entities know how to do their own change tracking regardless of which tier those changes are made on. As an architecture, self-tracking entities falls between DTOs and DataSets and includes some of the benefits of each.
Drawing from DataSet
DataSet on the client tier is very easy to use because there is no need to track changes separately or maintain any extra data structures that include change tracking information. DataSet takes care of serializing state information for each row of data. On the mid tier, applying the changes stored within a DataSet is straightforward. DataSets have also gained popularity because of the number of tools that work with DataSets, and because they are easily bound to many UI/presentation controls. Since it works in so many scenarios, for many applications there is never a need to transform data outside of a DataSet allowing a single paradigm to be used up and down the stack.
However, there are disadvantages to DataSets when used as the communication payload between tiers. The first is the cost of getting the data into a serializable format, and the second is that the DataSet serialization format is generally not very interoperable with other languages that are used to expose services. Another disadvantage of using a DataSet is that you can quickly lose the intent of your service call because so many kinds of things can be included in a DataSet. For example, if the service method is declared as:
DataSet GetCustomer(string id);
It is extra work to ensure that the DataSet that is returned contains only rows of data that pertain to “customers”. It is also more difficult to specify a service contract that says the DataSet is also supposed to return data for each customer’s orders and their order details.
Self-tracking entities share many advantages with DataSet. They also encapsulate change tracking information, which is serialized along with the data contained in the entity. On the mid-tier applying changes from a graph of self-tracking entities to a persistent context is equally straightforward. The Entity Framework will also provide tools for generating self-tracking entities and because these entities are just objects, they can be easily made to work with UI/presentation controls.
Design Notes
Inside a Self-Tracking Entity
There have not been final decisions about what exactly will be included inside of a self-tracking entity, but it is important to track:
-
The state of the entity, Added, Deleted, Modified, or Unchanged
-
The original value from reference relationship properties
-
Adds and removes from collection relationship properties
This information will be included with the data contract of the entity. As part of the code generation of each self-tracking entity, scalar and complex property changes will mark the entity as “dirty” meaning that its state will change from Unchanged to Modified.
Inside ApplyChanges
ApplyChanges is a new API on the ObjectContext and ObjectSet classes that attaches an entity graph and interprets the change tracking information stored in each entity. The design for discovering the change tracking information has not yet been finalized, but there are a couple of options available. One would be to code generate an interface as part of the T4 template for self-tracking entities as well as a version of ApplyChanges that knew about the interface. Another option would be fall back to runtime discovery of the particular properties using a convension and some of the new dynamic capabilities of the framework. The thing we want to avoid is causing the self-tracking entity implementation to have a dependency on any of the Entity Framework assemblies.
Posted in: C# and .NET| Tags: ADO.NET Entity Framework ORM Self-TrackingWhy not use the Entity Framework? It will save you lots of time
Subsonic, nHibenate, … … why not Entity Framework?
When you're creating a system for a client, that system has to represent functionality which are usable in the reality the client lives in. In short this comes down to the fact that the functionality and features of the system have to connect to what the client does and have to make the client solve problems / overcome challenge s/he would otherwise run into without the system (otherwise, why bother using it, right?). To be successful in this, the system should work with elements which are recognizable in the reality of the client: if the client works with customers who file orders for products, the system should work with customers who file orders for products (this is oversimplified, but it's for the example in a blogpost, not a book). But, what are these 'Customer', 'Order' and 'Product' exactly?
When discussing the project with the client, the client will tell you how s/he sees 'Customer', 'Order', 'Product' and how they relate to eachother: which information elements they consist of, how long they'll live inside the reality of the client, who must alter them etc. etc. This information is abstract, i.e. it's not physically available to you. To get a deeper understanding of it, you'll create a model out of this information, in one way or the other: the model contains the information obtained from the client and shows you the definitions of Customer, Order and Product and how they relate to eachother, perhaps other information as well if it benefits the model and its purpose. Now, the word 'Model' will make a lot of people think about visio diagrams or otherwise a picture of some sort. But that doesn't have to be the case. It can be anything, as long as it represents exactly the information you obtained from the client (or for DDD enthousiasts: the Domain Expert), so if you like to write lond-winded word documents, or write everything down in a text-based DSL, it's up to you.
As I also described in my essay linked above, you'll soon find out that a 'Customer', 'Order' and 'Product' in the reality of the client (and thus the system you're creating for this client!) are actually names for different groups of data elements. In other words: the instances of these three elements are tuples of data. If in your abstract model, the definitions of 'Customer', 'Order' and 'Product' are called entity definitions, the tuples are entity instances. So if I say: "ALFKI, Alfreds Futterkiste, Maria Anders, Sales Representative etc.", what does that mean? For the Northwind impaired: not much. For the people who recognize the first Customer record in Northwind's Customer table, it means: "It's a customer!". Well, almost. It's a Customer instance.
The system you're creating will deal with these entity instances in memory but also has to store them in a persistence storage (e.g. database). If for persistence storage a database is used, it means that these entity instances flow from memory to database table (insert/update) and back (fetch). If we define the reality of the application to be the state in-memory inside the application, we can define that an entity instance should be the same data tuple identified by the same identifying attribute (e.g. primary key, Id), if we save it or fetch it: if we fetch the ALFKI customer instance from Northwind on Monday morning 8 am. it has to be the same instance if we fetch it on Thursday afternoon at 4 pm (unless it's been deleted by someone of course). It might be that some attributes (fields) have changed a value, but it is the same instance.
However, looking at the data tuple's contents, they're just a bunch of strings and other constants. So this data tuple only becomes an entity instance if there's a valid entity definition in the same space (e.g. memory, database, application) to give it context. In other words: if you want to be able to talk about Customer, Order and Product in the application, as well as the database, you've to have a definition of these entities available where you work with the data tuples.
As we've already made the abstract entity model (in the form you like, e.g. a chalkboard drawing with foodstamps, knock yourself out, as long as it represents the exact information it should represent), why not use that information to become our entity definitions we need to give the data tuples context? This is called projection: we project this information onto a different space (e.g. program language, storage structure) and the result of that projection is the element we can use inside that space. The advantage of this is that the projection result isn't something that fell out of the sky: it is based on the result of analysis with the client or Domain Expert. As 'projection' sounds rather abstract, what is it exactly? Think about it like a transformation of a definition from one domain to another.
Take our abstract Customer entity definition. It's a definition of the attributes (fields/data elements) which together form the Customer: some ID which is unique, a company name, contact person name, title of the contact person etc.. If you see that entity definition, could you write a .NET class which represents that definition? I think you can . That's called a projection: you projected the abstract entity definition onto a .NET language. So a C#/VB.NET class which is the projection of an abstract entity is the projection result of that entity and can be used inside that space (C#/VB.NET/.NET) as the representative of that abstract definition. This means that we can use a Customer, Order and Product class which are the projection of these abstract entities onto for example C#/VB.NET in our C#/VB.NET application to give a Customer, Order and Product instance (data tuple) meaning. If we load the same data into an instance of a random other class (or an object array for example), you'll see a bunch of constants, values. But does it mean the same? You can interpret the data as if it's a Customer instance, but is that correct? In other words: you need the definition of the Customer to give the data meaning: create an instance of the projection result (class) and store the data tuple (customer entity instance) inside that class instance so the data inside the class instance has meaning: it is a Customer instance.
The same can be said about the persistent storage. Let's assume the data tuples are stored in a relational database. Because data tuples are just that: groups of constants, we need an entity definition to give them context: to give them meaning. In the relational model, these definitions are called tables, views and select queries (as by Codd/Chen's definition: a query is also an entity). So if we project our abstract entity definitions onto the relational model, we get representing elements which we can use in that space. Some will pick the table as the form they want to work with, others will pick a view. Both will have the same characteristic feature: they represent the abstract entity definition they're a projection of, they give meaning to entity instances of the entity they're a projection of.
For your Order system you need two projections of the same entity definitions: one on a .NET language, and another one on the relational model used in the relational database of choice (e.g. Oracle). As we've seen above, this results in Customer, Order and Product classes and Customer, Order and Product tables (or views, if you like views). Both projection results live inside a reality with its own rules and boundaries: the .NET classes live in the OO world of .NET, the tables live in the world of relational schemas, algebra and set theory.
Earlier in this post we've seen that an entity instance (data tuple) has the same meaning in the application's space whatever you do: working with the Customer instance represented by the ID 'ALFKI' means you're working with that instance, not with a random instance but with the instance. Inside the persistent storage, the instance is stored in a row which is defined by the table (or view) it is part of, i.e. the table definition (which happens to be the projection result of the Customer entity definition onto the relational model!). In memory the instance is stored in an instance of the result of the projection of the same definition onto the .NET language of choice, i.e. the Customer class.
However these two worlds don't live together in the same space: transfering an entity instance from its entity class instance (customer object) to the table row inside the database and back could be seen as a transformation: perhaps the entity is stored inside the database in two or more tables. Perhaps the projection on the .NET language resulted in multiple classes. For the application however, they must look like they live together: the transformation between the two worlds should just be there, it should 'just work', so the developer writing the system for the client doesn't have to worry about it. This is the service provided by an O/R mapper: it makes sure that the entity instances can be transported to the persistent storage (where they're stored in instances of the projection result on the relational model (i.e. table / view)) and back, and they keep the same meaning.
If a class definition C is the projection of an abstract entity E and a table definition T is also the projection of the same entity E, isn't it possible to project C out of T? or T out of C? Given the rules and boundaries of the spaces T and C live in respectively, and the projection rules of E onto C and T, one can define a projection from T to C and from C to T. This is what most of you are doing today: you pick an O/R mapper, you start with an abstract entity model, in one form or the other, work with it to create either tables or classes and tell the O/R mapper of choice to produce the other side. There are some variants on this but it more or less comes down to this, or in the ideal situation where you start from scratch and have the abstract entity model which is then used to produce both the tables and the classes. Some people will now argue that their .NET classes are way different than any table, and the classes follow the application's needs, but frankly that's not true: the classes written in such an application haven't fallen out of the sky either. If a Customer, Order or Product class has to be created, how is decided which fields are defined in these classes? Exactly, by projecting the abstract entity model.
he architecture of the ADO.NET Entity Framework, from the bottom up, consists of the following:
- Data source specific providers, which abstracts the ADO.NET interfaces to connect to the database when programming against the conceptual schema.
- Map provider, a database-specific provider that translates the Entity SQL command tree into a query in the native SQL flavor of the database. It includes the Store specific bridge, which is the component that is responsible for translating the generic command tree into a store-specific command tree.
- EDM parser and view mapping, which takes the SDL specification of the data model and how it maps onto the underlying relational model and enables programming against the conceptual model. From the relational schema, it creates views of the data corresponding to the conceptual model. It aggregates information from multiple tables in order to aggregate them into an entity, and splits an update to an entity into multiple updates to whichever table contributed to that entity.
- Query and update pipeline, processes queries, filters and update-requests to convert them into canonical command trees which are then converted into store-specific queries by the map provider.
- Metadata services, which handle all metadata related to entities, relationships and mappings.
- Transactions, to integrate with transactional capabilities of the underlying store. If the underlying store does not support transactions, support for it needs to be implemented at this layer.
- Conceptual layer API, the runtime that exposes the programming model for coding against the conceptual schema. It follows the ADO.NET pattern of using Connection objects to refer to the map provider, using Command objects to send the query, and returning EntityResultSets or EntitySets containing the result.
- Disconnected components, which locally caches datasets and entity sets for using the ADO.NET Entity Framework in an occasionally connected environment.
- Embedded database: ADO.NET Entity Framework includes a lightweight embedded database for client-side caching and querying of relational data.
- Design tools, such as Mapping Designer are also included with ADO.NET Entity Framework which simplifies the job on mapping a conceptual schema to the relational schema and specifying which properties of an entity type correspond to which table in the database.
- Programming layers, which exposes the EDM as programming constructs which can be consumed by programming languages.
- Object services, automatically generate code for CLR classes that expose the same properties as an entity, thus enabling instantiation of entities as .NET objects.
- Web services, which expose entities as web services.
- High level services, such as reporting services which work on entities rather than relational data.
What's New in ADO.NET 4.0
The following features are new in ADO.NET with the .NET Framework version 4.
ADO.NET Entity Framework
The Entity Framework is part of a multi-release strategy to decrease the amount of coding and maintenance required for developers by enabling them to program against data models defined in terms of entities and relationships. For more information, see Entity Framework Overview.
The following features are new to the Entity Framework in .NET Framework 4.
Persistence-Ignorant Objects
You can use your own custom data classes together with your data model without making any modifications to the data classes themselves. This means that you can use "plain old" CLR objects (POCO), such as existing domain objects, with your Entity Framework application. For more information, see Persistence Ignorant Objects (Entity Framework).
Deferred Loading of Related Objects
With deferred loading, also known as lazy loading, related objects are automatically loaded from the data source when you access a navigation property. For more information, see Shaping Query Results (Entity Framework).
Functions in LINQ to Entities Queries
The EntityFunctions and SqlFunctions classes provide access to canonical and database functions from LINQ to Entities queries. The EdmFunctionAttribute allows a CLR method to serve as a proxy for a function defined in the conceptual model or storage model. For more information, see Calling Functions in LINQ to Entities Queries.
Customized Object Layer Code Generation
You can configure the ADO.NET Entity Data Model Designer to use text templates to generate customized object layer code. For more information, see How to: Customize Object Layer Code Generation.
Model-First Support
The Create Database Wizard enables you to do conceptual modeling first, and then create a database that supports the model. For more information, see How to: Generate a Database from a Conceptual Model.
Complex Type Support
The ADO.NET Entity Data Model Designer now supports complex types. For more information, see the following topics:
* How to: Create and Modify Complex Types
* How to: Add a Complex Type to an Entity Type
* How to: Map a Function Import to a Complex Type
* How to: Map Complex Type Properties to Table Columns
Naming Service
The Entity Data Model Wizard and the Update Model Wizard provide the option of using singular or plural forms of Entity, EntitySet, and NavigationProperty names to make application code more readable. For more information, see Choose Your Database Objects Dialog Box (Entity Data Model Wizard) and Choose Your Database Objects Dialog Box (Update Model Wizard).
Improved Model Browser Functionality
The Model Browser window of the ADO.NET Entity Data Model Designer enables you to delete objects from the storage model and to search the conceptual and storage models for a specified string. For more information, see Model Browser Window and How to: Delete Objects from the Storage Model.
WPF and Silverlight Designer
In Visual Studio 2010, various designer improvements have been made to help create WPF or Silverlight applications.
* Improved Support for Silverlight
In Visual Studio 2008, you could install the Silverlight Tools to create Silverlight applications in Visual Studio. However, the designer support for Silverlight projects was limited to a read-only Preview window. In Visual Studio 2010, the designer support for Silverlight and WPF projects are now the same. For example, in Silverlight projects you can now select and position items with the mouse on the design surface.
* Support for Multiple Platform Versions
In Visual Studio 2008, control design times were able to target only the latest WPF platform version. In Visual Studio 2010, this support is extended across multiple platforms, including design-time support for WPF 3.5, WPF 4, Silverlight 2, Silverlight 3, and future platform releases. As the same extensibility API exists for all these platforms, control design-time authors can easily write one experience and share it across the control runtimes for each platform.
* Visual Databinding
The new data binding builder enables visual construction and editing of bindings without typing XAML.
* Auto Layout
Layout improvements include a more intuitive Grid designer and better support for automatically sizing user controls.
* Improved Property Editing
The Properties window now enables visually creating and editing Brush resources.
Posted in: C# and .NET| Tags: NET Database .NET 4.0 New ADO.NET Information framework linq model entity objects loading ado