Archive

Posts Tagged ‘NHibernate’

Frameworks 2013 and IDesign’s Method

April 28, 2013 2 comments

Architects and developers alike have firmly adopted the SOA revolution and with it, the special challenges the paradigm commands. Some have successfully navigated the issues but many are bearing the battle scars from failed attempts.  The SOA movement can benefit from tried and true methodologies and tools.  Seasoned architects who have practiced SOA for years have greatly improved all aspects of the software process, from design to implementation, testing and Project Design utilizing IDesign’s “Method”. If you are not currently using the Method, I suggest that you read about it at the IDesign web site.

I have been using a tool that will help both the Architect and developer’s SOA efforts. The tool has been used for a number of years and the latest release now supports the Method. The combination of the two tells a compelling story that is the subject of this blog.

Method practitioners know that the modeling starts with a “Static Diagram” depicting the various services the architect has designed.  Instead of creating the diagram in PowerPoint, we use Frameworks 2013, a Visual Studio add-in to develop the model.

Static Diagram

In this rather small static diagram, there are 5 services. If you’re like me, you’ll want to keep your solutions small so they can compile fast and as a result, form a perfect environment in which to write and test code quickly. A one-to-one relationship between solution and service has many benefits which I will delve into in a subsequent blog of this series. For this static diagram, you would therefore have 5 solutions to create. Each of the 5 solutions would have a number of projects. Typically, the architect or developers will need to create these solutions and the projects within. Frameworks will do that work for you at the click of a button. But the story only begins there; let’s dig in a little further.

The next set of models to create would be the Call Chains. Like the Static Diagram, the services you draw with PowerPoint are just colored rectangles with lines and as such, are simply one step up from using a paper napkin.  Conversely, Frameworks treats them as a first class citizen; you may be surprised as to what is possible when the model truly becomes a living, breathing aspect of your work.

Call Chain

Only the services shown on the Static Diagram are allowed on the call chains as dictated by the Method. Logically, the culmination of all call chains dictates the dependency diagram. Frameworks can utilize the information to produce it without further work by the architect.

Dependency

The WCF Services diagram is also supported. A host is represented by a red box that you drag on to the “design surface”. You then drag Managers, Engines and Resource Access services into the host as you have designed it. Once again, the model represents valuable information that can be used for great benefit; in this case, a host solution can be created and even deployed. As you will see in a future article, Frameworks can produce a complete vertical slice of the application without a single line of code being written by the human being.

Host

As stated earlier, the static diagram can create a solution for each service. Frameworks will utilize any number of Visual Studio project templates to setup the solutions and projects in a manner that is warranted by your organization – you have complete control.

Once the solutions have been created, it is time to create the detail design. That is to say, you create service contracts and the data contracts it will consume and produce. This is where the power of the tool comes to life.

Detail Design 1.2

Optionally each operation can have a DataContract as input, a parameter list, or both. The tool imposes no limits on what you can currently do with WCF.

Suppose the Service is of type Resource Access, you will want to model the Entities, ala EF, in the same model.  You might also want to reverse engineer an existing database. If you use NHibernate, you would have to write all of those ugly XML “hbm” files.  Why do that by hand when it doesn’t add any real business value? The answer is that you shouldn’t, you would want the tool to write it for you.

On many occasions you might want to map some or the entire data contract to an entity and back. That mapping code is also created by the tool. Moreover, you might not want to share your data contracts from the Access layer through the engine to the manager. At each layer, you can copy the data contracts from one model to another, make adjustments and the mapping code will be generated.

Detail Design 2.1

It is important to note that all code artifacts are optional and when you do use them, there are plenty of places to inject your own code. Further, all code that you write to augment the generated code are placed in partial classes and as such, your code is never modified.

The road-map includes plugging the modeling tools into project management tools such as JIRA and TFS, creating NuSpec files for each service, creating build definitions for Team City and TFS, and hooking in IDesign’s Project Templates.

The goal of this blog was to merely give you a flavor of what is possible with Frameworks 2013. There are many more features to cover and a fair amount of detail to investigate. We will do that in subsequent entries of this multi-part blog series.

Frameworks – A Domain Specific Language

November 24, 2010 3 comments

Domain Specific Languages (DSL) can be a tremendous performance boost for many software development environments. When used properly, it can dramatically reduce tedious hand-written code, decrease defect rates and increase code readability. They can also help bridge the gap between the developer and business personnel.

I have been working with a DSL named Frameworks that brings forth an entire architectural framework into focus. It has been used in several enterprise-grade products and development is continuous and on-going.

Frameworks, while easy to use, deserves an in-depth discussion on its philosophies, artifacts, coding techniques and limitations. For these reasons, this blog will be multi-part, addressing a different topic with each post.

What is Frameworks?

It is a DSL that utilizes a Model first approach to development. There are some excellent writings on this subject and I encourage you to explore it if you have not already done so. The Domain Model provides a soft transition of knowledge from domain level expertise to developer ‘speak’. It is a model that business analysts digest quite easily and one that the developer can use in most every phase of a project. Domain Models look similar to a class diagram as shown below.

Frameworks loosely uses the Domain Model as the hub for many artifacts. Amongst them are business objects and their interfaces, data-access objects and their interfaces, ORM and dependency injection configuration and others.

The goal of the Frameworks is therefore several-fold:

  1. Help to bridge the gap between business analyst and developer roles using the domain model.
  2. Use the domain model to generate artifacts so that the developer does not have to write tedious, error-prone code.
  3. Generate the code utilizing best practices that build on the work of others.
  4. Allow the developer to choose between NHibernate and Microsoft’s Entity Framework to achieve object-relational-mapping (ORM).
  5. Take advantage of dependency injections (DI) systems such as Microsoft Unity into the generated code.
  6. Allow for internal caching of ‘category’ type data upon simple declaration.
  7. Allow the developer to declare database partitioning (‘sharding’) without having to write the code to do so.

As you can see, the project is quite ambitious. This series of blogs will attempt to describe in various levels of detail, how these goals have been realized.

The next blog in the series will discuss the domain model in detail and setup some of the philosophies around the architecture.

%d bloggers like this: