session e-mere mm .net framework 4portal.dfpug.de/dfpug/dokumente/konferenzen/vfp... · none of...

MM .NET Framework 4.0 17th European Visual FoxPro DevCon 2010 © 2010 Kevin McNeish (Group .NET) V-MERE • 1

Session E-MERE MM .NET Framework 4.0

Kevin McNeish Oak Leaf Enterprises, Inc.

www.oakleafsd.com

Contents You may ask why you need a Framework when you already have Microsoft's .NET Framework - the answer is simple. Microsoft's .NET Framework supplies you with all the basic building blocks you need to create world-class desktop and Internet applications. However, with over 2,000 .NET base classes to choose from, it's like walking up to a construction site that contains piles of building materials. Everything is there, but you don't know where to start!

You may be asking:

• How can I create a .NET application that is scalable from the desktop to the Internet? • What's the best data access strategy with ADO.NET? • How can I build an application that works equally well with SQL Server and Oracle? • How can I apply design patterns in my code to create well designed, object-oriented software? • What are business objects and how can they help me create flexible, maintainable, and extensible appli-

cations?

17th European Visual FoxPro DevCon 2010 MM .NET Framework 4.0 2 • V-MERE (Group .NET) © 2010 Kevin McNeish

The Mere Mortals Developer's Guide The Mere Mortals Developer's Guide is the primary Framework documentation. First of all, it contains high-level overview information that explains the technologies used in Mere Mortals, so you know why we've chosen a particular path. It also contains plenty of "how to" information to help you make practical use of Mere Mortals Framework classes in your applications.

If you are new to the Mere Mortals methodology, you may want to begin by going through the tutorials in the Jump Start Guides. These guides take you step-by-step through each phase of the application development proc-ess. They do not provide the same in-depth discussion of methodology as found in this guide, rather, the goal is to give you a basic overview of the entire application construction process.

Under the Hood Documentation For the most part, you can use the functionality of MM .NET without needing to know what's going on behind the scenes, and we have designed MM .NET with this in mind. However, throughout the DevGuide we've in-cluded "Under the Hood" information for those of you who want to know more about what MM .NET is doing behind the scenes. This information includes UML class and sequence diagrams as well as detailed descriptions of object interactions. We've clearly labeled these sections, so if this is more information than you want to know, feel free to skip it!

MM .NET Overview "Why do I need another framework such as MM .NET if I've already got the .NET Framework?"

To answer this question properly, you must first understand "What is the .NET Framework?" The .NET Frame-work is two things:

• The Common Language Runtime (CLR) which manages the execution of .NET programs including memory management, garbage collection, exception handling, and assuring type safety.

• The .NET Base Class Libraries (BCL) which is comprised of thousands of classes including user inter-face classes and other core classes that provide object-oriented access to the services of the underlying operating system.

Building an application directly from the .NET base classes without an application framework is like being given huge piles of construction materials and being asked to build a house. Everything you need is there, but you don't know where to begin.

In contrast, MM .NET provides a basic foundation and structure on which to build your applications. A big part of this is higher-level objects that provide services for your applications, such as:

• Business components • Database management • Intelligent Data binding • Security • Localization • Exception Handling and logging

None of these are out-of-the-box components in .NET, although they are services most applications need. Rather than recreating these services each time you create a new application, you need a framework that provides these components that can be reused in your Windows Forms, Web Forms, Web Service, and Smart Device applica-tions.


Architectural Guidance Are you painting yourself into a corner? How do you build a well-designed, flexible, and scalable application in .NET? Using the basic project templates in Visual Studio is not going to get you there. For example, when you create a new Windows Forms application in .NET, the new project the only thing you get is an empty form, a program file, and assembly information file as shown here:

When a developer creates their first .NET application and sees this, the usual reaction is "Now what?"

In contrast, we've created templates for MM .NET applications that take you much further along the curve, and provide design guidance. For example, when you build a new MM .NET Windows Application, it asks if you want to create a new business object project. If you reply "yes", it adds a new business object project to your solution as shown here:

Mindshare - The Benefit of "Open Source" One of the greatest benefits to using a commercial framework rather than a homegrown one is the mindshare created by many developers using the framework to create a wide variety of applications. The framework is tested, stretched, extended, and enhanced in ways that an internal framework built by an individual company can never achieve.

We have been fortunate to have many high level developers use our Mere Mortal Frameworks, and they have added tremendous value to MM .NET with great new ideas, bug fixes, and enhancements.

Since we provide source code with Mere Mortals, developers can easily see what's going on behind the scenes. This approach has been a tremendous benefit to us and our users, similar to what is achieved with open source languages and tools. For example, when a developer has framework source code it's much easier for them to determine how best to override a particular method because they can see for themselves what's going on behind the scenes.


Design Patterns - "Doing it Right" Choosing an application framework is very much like choosing a marriage partner-especially when it comes to ending a bad relationship! This is not only true of commercial frameworks, it's also true of homegrown frame-works. I've worked with a number of companies who have had bad experiences trying to pull themselves out from under a framework built in-house by well-meaning developers who had little framework design experi-ence.

So how can you know if the framework you are choosing will result in a happy, productive relationship, or one filled with regret? Although it's not a silver bullet, the use of standard object-oriented design patterns is a great step in the right direction.

Design patterns provide both developers with proven solutions to object-oriented problems. For example, one of the biggest complaints developers have against frameworks is they force you to do things a particular way. How-ever, if a framework architect subscribes to the guideline of "programming to an interface rather than an imple-mentation", it allows developers to easily change the framework that suit their needs.

When adding features to MM .NET, we always think "someone isn't going to want to do it this way", and we always provide a way for developers to change or extend how we've implemented a feature. Another great way to provide this flexibility is by means of the Factory and Hook patterns.

You can create a wide variety of applications in MM .NET. The following sections provide an overview of these different types of applications.

Windows Presentation Foundation Windows Presentation Foundation (WPF) is Microsoft's latest technology for building Window applications in .NET. Although Microsoft has done a fairly decent job at creating a good platform for developing Windows desktop applications, MM .NET fills in many of the holes you find in .NET Windows Presentation Foundation. MM .NET enhances the basic .NET WPF controls, providing functionality security, localization, and so on.

In addition, MM .NET guides you in creating WPF applications that are flexible, high-performance, and well-designed. By promoting the use of business objects, MM .NET helps you reuse your application logic in differ-ent types of applications.

Silverlight Applications You can build visually stimulating, high performance Silverlight applications with MM .NET. You can use the same business objects you have created for your other projects and by means of RIA services communicate with the business tier for running business processes, retrieving and updating data, as well as enforcing business rules.

Web Forms Applications A Web Forms application is a standard Web application with a user interface including Web controls such as text boxes, labels, list boxes, and so on. Again, MM .NET fills in many of the gaps found in out-of-the box Web Forms technologies with enhancements including generic data access, intelligent data binding, security, localiza-tion, and so on.

MM .NET guides you in creating flexible Web Forms applications that are scaleable, and high performance, and well -designed by the use of business objects.

Web Services A Web Service is a Web application that does not have a user interface. When Microsoft first released .NET it announced that .NET was "a platform for building, consuming, and deploying Web Services". Although they've changed this original message, Web Services can allow your applications to communicate with other Web appli-cations running on any type of server.


Windows Workflow Windows Workflow is Microsoft's general-purpose programming framework for creating reactive programs where business rules and flow of control are represented graphically. WF provides a higher level of abstraction, making it easier to understand business process.

MM .NET business objects can be called directly from Window Workflow activities, often allowing you to reuse your existing application logic.

Windows Communication Foundation Windows Communication Foundation (WCF) is Microsoft's communication subsystem that allows applications in one machine or across multiple machines to communicate. It is a service-oriented programming model for distributed computing. MM .NET allows you to use WCF to physically distribute the tiers of your application.

Windows Forms Applications Note that Windows Forms technology is officially dead-ended in .NET and has been replaced by Windows Presentation Foundation. That said, MM .NET still supports the creation of Windows Forms application. A Windows Forms application is a standard, Windows desktop application. Although Microsoft has done a fairly decent job at creating a good platform for developing Windows desktop applications, MM .NET fills in many of the holes you find in .NET Windows Forms. MM .NET enhances the basic .NET Windows Forms controls, providing functionality such as generic data access, intelligent data binding, security, localization, and so on.

Smart Device Applications Smart Device Applications implement the .NET Compact Framework, which is a subset of the full .NET Frame-work. This includes devices running Windows CE and PocketPC. Although you can currently use MM .NET business objects in a Smart Device application, we are currently working on providing far more support includ-ing intelligent data binding, security, and localization.

Software Development Processes As part of our "best practices" recommendations for .NET development, we recommend using a formal software development process. At Oak Leaf Enterprises, we use both the Unified Process and the Unified Modeling Lan-guage.

The Unified Modeling Language Many software developers create complex software systems without an architectural model in order to "save time." In reality, they spend far more time reworking, backtracking, and duplicating efforts. A common denomi-nator in projects that are behind schedule or architecturally unsound is little or no analysis and design.

In contrast, software modeling helps in managing complex systems, decreasing the cost over the life of a project, and actually reducing time to market! Rather than delaying the delivery of a product, good analysis and design can actually speed its completion! To create software models, you need a modeling language. A modeling language specifies the graphical notation used to express software designs. However, this raises the question, which methodology should you use? As recently as 1996, the object-oriented community was fragmented into more than 50 methodology camps. There were similarities between methodologies, but their notations were different, causing division within the OOP community. Because software development was a relatively new engineering discipline, it did not have standard notations common in architecture, electrical, and electronic engineering.

In the period of 1995-96, three of the leading object-oriented gurus, Grady Booch, Ivar Jacobson, and James Rumbaugh (a.k.a "The Three Amigos") joined forces under Rational Software Corporation to create a single, standardized methodology they called the Unified Modeling Language (UML). The UML quickly became the defacto standard modeling language for object-oriented software development and is taught in many universi-


ties. In addition, Visual Studio 2002 and 2003 have built-in capabilities for forward and reverse engineering with tools such as Visio and Rational XDE. Visual Studio has its own Class Designer which mostly holds to UML standard notation.

Note: I (Kevin) co-wrote a book Professional UML With Visual Studio .NET (Wrox Press, ISBN 1-86100-795-7) that gives a high level overview of the UML and the Unified Process, and then gives you details on how to do UML modeling with Visual Studio .NET and Visio.

The Unified Process The Unified Process divides the software development process into the following phases:

Inception - The initial phase where you establish the business rationale and scope of the project.

Elaboration - In this phase you collect more detailed requirements, do high-level analysis and design to establish a baseline architecture, and create a plan for construction.

Construction - During construction, you build the system in a series of iterations. Each iteration involves analy-sis, design, coding, and testing. Each iteration is finished with system tests and a demo to the user.

Transition - This phase includes beta testing, performance tuning, and user training.

If you're following the Unified Process, it's not until the Construction phase you begin using the Mere Mortals .NET Framework. During construction you design and create business objects that become the building blocks of your application.

Agile Software Development Over the past several years Agile Software Development has gained quite a following including large companies such as Microsoft. Here is a list of Agile principles as outlined in the Agile Manifesto: http://agilemanifesto.org/:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and the support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to main-tain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior -accordingly.

Some of the primary ways MM .NET can help in agile software development is its use of business objects and design patterns.

When you put the majority of your applicatoin logic in business objects it is much easier to do Test-Driven-Development since much of your testing can be done outside the context of the UI. The abundant use of time-tested design patterns in MM .NET makes it easy to change Framework behavior as well as the applications that are built on it. This makes it far easier for your applications to adapt to changes in requirements over the life of the project.


Business Object Architecture As shown in the following UML class diagram, MM .NET business objects are composed of four main classes

• The main business object class (OrderDetail) • An associated entity class (OrderDetailEntity) • A business rules class (OrderDetailRules) • A data access class (OrderDetailDataAccess - optional)

While some frameworks wrap all of this functionality into a single class (sacrificing performance and extensibil-ity for the sake of simplicity), MM .NET business object architecture gives far more extensibility and run-time performance for developers building real-world business applications.

Model-View-Controller Design Pattern This architecture maps nicely into the Model-View-Controller design pattern. The main business object class is the Controller, the Entity class is the Model and your user interface is the View. MM .NET data binding uses the Observer design pattern to bind to your entity objects providing a loosely coupled model that is characteristic of the Model-View-Controller design pattern.


Composition There is a composition relationship between the Business Object the Entity, Rules, and Data Access objects. Composition is defined in The Unified Modeling Language User Guide as: "A form of aggregation with strong ownership and coincident lifetime of the parts by the whole; parts with non-fixed multiplicity may be created after the composite itself, but once created they live and die with it; such parts can also be explicitly removed before the death of the composite."

This is definitely true of the relationship between these objects. The Business Object has strong ownership of the Entity, Rule, and Data Access Objects.

Extensibility In an object-oriented architecture, whenever you break out a set of functionality into a separate object you gain extensibility and flexibility. For example, business rule objects can be used by multiple business objects or busi-ness process objects, which is important since business rules don't always apply to a single object! In addition the MM .NET business layer architecture allows you to subclass and extend business rule, business entity and data access objects to take full advantage of object-oriented inheritance. This architecture also allows the busi-ness object to return different "shapes" of entity objects. For example, you can return an entity object that has all properties corresponding to columns in a data table when you want to edit, or you can return an entity object that only has a primary key and description when binding to read-only lists. This just isn't possible or practical when these are rolled into a single business object class.

In addition, all business object classes are marked as partial classes so you can easily extend generated business layer code without losing any of your changes!

Performance The Rules, Entity, and Data Access objects are not instantiated at run time until they are first accessed (lazy instantiation) which translates into measurable speed increases. If you don't need to check business rules, the Rule object is not instantiated. If you don't need to access data, the data access object is not instantiated. In addi-tion, Entity objects are light-weight objects that can be quickly passed across physical tiers of an application.

The Business Object class is the controller class in the MM .NET business object architecture. You add custom methods to this class that contain the behavior associated with a specific real-world entity (such as an Invoice, Inventory, a Customer, and so on). mmBusinessObject is the base class for all business object classes in MM .NET. Here is an example of an Inventory business object:

The Business Object class is the main class that your code interfaces with. When you want to use the services of a business object, you instantiate the object and call one of its methods--one of your custom methods or a built-in method inherited from the mmBusinessObject class.

When retrieving data the business object passes the responsibility off to its associated Data Access object:

When saving data, the business object automatically calls the Business Rule object to validate business rules before calling on the Data Access object to physically save the data:


All of this happens behind the scenes. You can just interact directly with the Business Object and it takes care of the rest for you.

Understanding Business Entity Objects Entity objects are mostly comprised of properties that represent the attributes of real-world entities and provide strongly typed access to data associated with a business object. Entity objects are very light weight and serializ-able so they can be passed between physical tiers of an n-tier application. mmBusinessEntity is the root base class of all entity objects in an MM .NET application. Here is an example of an EmployeeEntity object:


The Benefits of Entity Objects By default, data access in ADO.NET is untyped and fraught with potential run-time exceptions. Take for exam-ple the following line of code:

string CustomerID = (string)Row["CustomerID"];

The first thing to note is that "CustomerID" is a string that is evaluated at run time. If you mistype the column name, (for example, "CustID"), the compiler will not catch the error and you will get a run time exception when this line of code executes.

The second thing to note is the explicit cast to a string. When you perform an explicit cast, the compiler assumes you know what you're doing. So, if you incorrectly specify the type as shown in the following line of code, the compiler will not catch the error, and you will get a run time exception:

int CustomerID = (int)Row["CustomerID"];

In contrast, when using MM .NET Entity objects, you solve both of the problems mentioned above. Take for example the following line of code:

string CustomerID = OrderEntity.CustomerID;

In this case, CustomerID is a property on an object, so Visual Studio IntelliSense shows you a list of -OrderEntity properties to choose from (you no longer have to go to the Server Explorer to see what the table column names are):

Even if you have ignore IntelliSense and have a typo on the property name, the compiler will catch the error at compile time rather than run time.

Also, when it comes to strong typing, the compiler will also catch an error where you specify the wrong type: int CustomerID = OrderEntity.CustomerID;

In summary, MM .NET Entity objects allow you to write code that can be verified by the compiler to help avoid runtime exceptions!

In MM .NET, you have the choice of using either Microsoft's Entity Framework, or MM .NET "classic" entity objects.

You can mix and match classic MM .NET entities and Entity Framework entities in a single project. However, a particular business object can only use one type of entity or the other. If you are using classic MM .NET entities, the associated business object's EntityCentric property is set to true. If you are using Entity Framework entities, both the EntityCentric and EntityFramework properties are set to true. These are set automatically for you by the MM .NET Business Layer Generator.

Entity Framework Entity Objects Starting in version 3.6, MM .NET provides integration with Microsoft's Entity Framework. Some of the benefits of using the Entity Framework instead of MM .NET classic entities are:

You can use Language Integrated Queries (LINQ) to retrieve entities from the back end. These are strongly typed queries that you can easily construct with IntelliSense, and the compiler can check their validity at design time (as opposed to strings that are evaluated at run time).


Entity Framework entities are pure properties with no underlying DataRow, DataTable or DataSet (as is the case with MM .NET classic entity objects). This makes your entity objects lighter and faster.

You write queries in a database-neutral syntax (either LINQ or Entity-SQL) and the Entity Framework providers translate them to the correct database syntax for you. So, if your application needs to access multiple kinds of data (i.e. SQL Server, Oracle, DB2) you don't have to maintain multiple versions of stored procedures or dy-namic SQL statements.

The Entity Data Model The Entity Data Model (EDM) is a diagram in which you can visually design your entity objects. For example:

When you rebuild your project, Visual Studio generates an entity class for each entity shape in your Entity Data Model. You can either manually create entities in the diagram or (more commonly) you can automatically gen-erate entity objects from your application's database using the Entity Data Model Wizard.

Note: The Entity Data Model only generates one portion of your business object--the entity object. It doesn't generate the main controller class or business rules class. You should still use the MM .NET Business Layer Generator to create these.

When using the Entity Framework, you do not access the back end database directly. Instead, all queries are executed against the Entity Data Model (EDM) that is part of your project. The Entity Framework converts your queries to the appropriate back end database syntax.


The Object Context In addition to the entities that are generated from the Entity Data Model, Visual Studio also generates a single Object Context class. This is the main class you use to interact with the Entity Data Model to perform queries that retrieve entities from the back end.

The Object Context class doesn't appear on the Entity Data Model, but if you would like to see a visual represen-tation of it, you can drag your application's Entity Data Model (the file with the .edmx extension) onto a class diagram. This adds all generated entities and the object context to the diagram. For example:

Notice there is an "Entity Set" property on the Object Context for each entity in the diagram. These entity sets are what you create queries against in your business object code. You can return a single entity or a list of enti-ties. For example:

public EmployeeEntity GetEmployeeByID(int employeeID) { IQueryable<EmployeeEntity> query = from e in this.ObjectContext.EmployeeEntitySet where e.EmployeeID == employeeID select e; return this.GetEntity(query); }

When generating business objects with the MM .NET Business Layer Generator's Entity Framework checkbox selected, the BLG adds an ObjectContext property to the main business object controller class. This provides easy access to the Object Context for creating queries. Other than that, you don't need to access the Object Con-text directly because MM .NET wraps up its functionality in a standard data access class (for example, mmDataAccessSqlEF). When you call business object methods such as SaveEntity(), DeleteEntity(), and -CancelEntity(), behind the scenes, MM .NET issues the corresponding commands to the Object Context for you.

MM .NET Classic Entity Objects Prior to version 3.6, MM .NET's "classic" entities were classes that contained strongly typed properties that were wrappers around an underlying DataRow. Behind the scenes, the ADO.NET DataSet and DataTable are used to track changes and issue updates. Ultimately, when using MM .NET classic entity objects, you don't have to work directly with the underlying data--you can simply work with strongly typed entities and entity lists.

In cases where you really need a DataSet/DataTable, you can choose to use classic MM .NET entity objects and directly access their underlying untyped data.


Understanding Business Rule Objects The main responsibility of a business rule object is to enforce business rules. For example, the Rule object may check that required fields are filled, values are between a particular range, and strings are below a maximum length. mmBusinessRule is the base class for all business rule classes in MM .NET. You can create your cus-tom business rules, but you can also manually create your own business rules. Here is an example of an -InventoryRules object:

Broken Business Rules and Application Warnings The MM .NET business rule class tracks two types of errors:

• Broken business rules • Application warnings

Broken business rules (such as required fields that are empty) prevent data from being saved. In contrast, a warning is simply a message that can be displayed to the user as a word of caution, but still allows data to be saved. For example, you may want to warn the user that, although a specific piece of information is not required, if they don't enter this information then something may go wrong.

Understanding Data Access Classes Rather than placing data-specific logic in business objects, all data-specific logic is placed in data access objects instead. At runtime, a data access object is attached to a Business Object when an attempt is first made to re-trieve or update data.

Generic Data Access Classes You can either choose to use dynamic SQL or stored procedures for retrieving and updating data. If you use dynamic SQL, then your business object can simply use a generic, framework-level data access class.

mmDataAccessBase is an abstract base class from which all data access classes in MM .NET are derived. The following UML class diagram shows the different data access classes that are found in MM .NET:


When a business object needs to access data from a SQL Server database, it uses the mmDataAccessSql class. When it needs to access data from an Oracle database it uses mmDataAccessOracle, and so on.

Custom Data Access Classes If you use stored procedures for retrieving and updating data, you need to create a custom data access that knows how to properly call these stored procedures. For example, this OrderDetail business object has an asso-ciated OrderDetailDataAccess class:

The MM .NET Business Layer Generator can automatically generate custom data access classes for you, as well as stored procedures for retrieving and updating data

Using the MM .NET Business Layer Generator The MM .NET Business Layer Generator allows you to generate business and data access layer from an existing database such as SQL Server or Oracle. You can choose to generate from Tables, Views or Stored Procedures:


Why Generate Business Layer from Database Objects? At first glance, this may seem like driving the process the wrong way. Typically, you perform business object modeling first, then derive your database schema from the business layer. However, often developers create applications that must work with an existing database. If the database has been designed well, it contains con-straints, default values and other information from which business rules can be derived. In this case it's prag-matic to leverage the many hours spent designing and fine tuning your database into generating your business layer.

Tables in your database often represent real-world entities. For example, each of the following database tables represents a real-world entity:

Similarly, business objects also represent real-world entities:

The difference is that database objects only model the attributes of real world entities (such as Customer name, address, phone number) while business objects model both their attributes and behavior. Since we can at least derive business object attributes (as well as some business rules), it’s pragmatic to derive business object classes from database objects to help jump start the application development process.


Generating Data Access Layer from Database Objects Even if you don't use the Business Layer Generator to generate the business layer, you can use it to generate your data access layer. Specifically, if you are using stored procedures to retrieve and update data, the Business Layer Generator can generate stored procedures and associated data access classes for you.

Conclusion MM .NET has literally helped thousands of development shops make a successful leap to .NET and create ap-plications that are well designed, are high performance and truly satisfy the customer’s needs. To find out more about how MM .NET can help you make a successful leap to the .NET platform, check out our web site at www.oakleafsd.com.

session e-mere mm .net framework 4portal.dfpug.de/dfpug/dokumente/konferenzen/vfp... · none of...

Documents