Basic React Component Structure

Here is some sample code to create a basic react component

<pre>

<div>import React from 'react';
import ReactDOM from 'react-dom';

class App extends React.Component {
render(){
return (
<HelloWorld />
)
}
}

class HelloWorld extends React.Component {
render(){
return (

<div>

<h2>Hello World</h2>

</div>

)
}
}

export default App</div>


<div>//or ReactDOM.render(<App />, document.getElementById('app'));</div>

</pre>
Advertisements

Could not establish trust relationship for the SSL/TLS secure channel with authority

A frustrating issue I run into occasionally in calling web services on my Windows development machine is “Could not establish trust relationship for the SSL/TLS secure channel with authority”.  I usually have to think back and search on the internet how to fix it.

Certificates can be a little confusing and I’m one who just wants to do as little work as possible to get past irrelevant issues so I can get to what is important.  I know enough about certificates to use them and deploy them but I’m not an expert.  So what I have found works but there may be better solutions.

Anyway, here are a couple of ways I’ve resolved the issue.

First, if you just want to ignore all certificates and you don’t mind a hard-coded solution,  you can add this code to the client before calling the service: System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };

A second option is that you can use the manage certificates snap-in.  Navigate to the Personal\Certificates folder and copy the localhost certificate to the Trusted Root Certification Authorities\Certificates folder.

 

 

Type Sharing – Data Access Layer

To start off my “Code Structure” tag, I usually find developers create a big type library to hold all their types used across multiple libraries.  In my opinion, this violates the “Separation of Concerns” rule.

Another problem with this is developers tend to misuse the types and tightly couple code together such that a change to the type can potentially impact multiple areas.

For example, I’ve seen types meant for web service contracts used all the way down in the data access layer.

Another issue I’ve seen is types that have a ton of fields.  In many cases they have most of the fields in the corresponding database table.  By the way, I don’t necessarily believe that the types have to match the database table structure. 

I believe this issue is also what is described as the “God Class”.  Anyway one problem with this is that it can be confusing in code as to whether the objects of this type have been properly populated.  The default thinking should be it is always correctly populated by the data access layer but of course I’ve seen developers reuse a type and only partially populate the object.  They probably did this inadvertently from not thoroughly reviewing their code. 

So at least when coding in the data access layer and Update/Add APIs, I believe we should carefully select what fields are passed in.  All parameters and objects fields passed in should be assumed to be the exact values that will be stored in the database.

There are a few other issues with these “God Classes”.  One is type fields that are for calculations.  There is no good reason to pass these to the data access layer and cause confusion when reading the data access layer code.  Another issue is there is unnecessary payload being passed around.  And finally, the more fields you have to consider the more complex the API can be. 

Ideally, the data access Update/Add APIs should be simple processing of related data.

Code Structure

It’s impressive how much information there is on software development on the internet.  You don’t have to read books in order to develop applications.  It’s amazing how knowledgeable people are able the many programming languages and technical matters and how experienced they are.

But there is one thing I don’t see much of and that is how to organize code and projects.  And how to select the best third party libraries and solutions.

I have read many of the books and articles about the different ways you can solve problems.  There are all the different design patterns and architecture patterns.  Some of my favorites are

  1. Clean code
  2. Design Patterns – Elements of Reusable Object-Oriented Software.
  3. Refactoring To Patterns
  4. Patterns of Enterprise Application Architecture
  5. Patter-Oriented Software Architecture
  6. Refactoring

And I have some favorite Architecture Books

  1. Software Architecture In Practice
  2. Just Enough Software Architecture
  3. Software Architecture For Developers
  4. Documenting Software Architectures

And I luckily I read Code Complete back when I started my development career.

But there’s not much available on how to structure your projects and your libraries.  And what are the pros and cons of all the different ways that this has been done.

The most common structure I’ve experience is the multi-layer pattern.  It seems to be the most suitable and encourages “Solid Code”.

Anyway, when I have some special insight, I’ll be sharing my thoughts as to what seem to be best practices to me in organizing and structuring code.

Azure Functions

I created my first Azure Function today.  It was pretty simple to create.  The short-cut URL to get to these is functions.azure.com.

I just clicked the new function button and I chose HttpTrigger in C#.  Azure created a sample app to work with.

I decided to create a function that calls Google Translate.  It accepts some text to translate, language in and a language out.

Azure generates and displays the URL to the function for you.

I modified the generated code to accept json parameters.  I added some code I found to call the Google API.  I had to add a using statement for Newtonsoft.Json.  I also had to add the statement ‘#r “Newtonsoft.Json”’ at the top.  I assume that creates some kind of reference to the Newtonsoft library.

To call the function I used a restful API extension tool in chrome.  I added the header values for Accept and Content-Type and added the body and that was all that is needed to call the API.

I look forward to finding uses for the cool feature.

Here is a screen shot of the Azure Function code screen

pic1

Here is a screen shot of my rest client

pic2

 

 

Tool – EntityFramework Reverse POCO Generator

Recently implemented the “EntityFramework Reverse POCO Generator” in a project. 

Here is the link: https://visualstudiogallery.msdn.microsoft.com/ee4fcff9-0c4c-4179-afd9-7a2fb90f5838

It was easy to do and replaces the bulky edmx as well as makes it easier to keep your POCOs in sync with the database.

The script is editable and the code is available on github.  You can also alter the code for your own purposes.

For my project I modified these settings in the tt file:

  1. ConnectionStringName
  2. ConfigurationClassName
  3. UseCamelCase = false;
  4. Namespace
  5. AddUnitTestingDbContext = false;
  6. AutomaticMigrationsEnabled = false;
  7. AutomaticMigrationDataLossAllowed = false;
  8. Inflector.PluralizationService = null;
  9. Comment out pluralization – search for append

Unfortunately, the database has a security schema name with a period in the name so I had to modify the tool code to accept that but name it without the schema in the name.

After running the tool against the existing projects that reference the POCOs, I had to correct a few POCO elements that were named differently than the EDMX name them.  These all were related to foreign keys.