Hello,

I found a isolation problem when generating code because all classes are public, instead of internal.

In my opinion, this can lead us to a problem, because some programmers can instantiate a DataAdapter directly to creating/deleting/updating entities without using business layer.

I looked into *.template and saw that the access modifier "public" is hardcoded. I think it should be parametrized in the future to allow the "internal" access modifier.

Thank you. Hugo Caldeira

Adapter is organized in such a way that you don't need a reference to the dbspecific project to use the entities, I.o.w.: you can hide the adapter completely in a different piece of code. I'm not sure if your project is organized in such a way that this is possible though. Internal adapter are not useful, as they then only are accessable inside the dbspecific project, which is of course not what you want.

Hi, thanks for fast replay.

You are right, if we use the default structure of generated projects, the classes must be public, if not, we cannot create classes from our assemblies. But as I state before, I want to encapsulate LLBLGen classes inside a layer.

To accomplish this, I had to change the templates to not generate projects *.cproj, then I included the files manually in my project, example:

DataAccessLayer.csproj [My project manually created] DatabaseGeneric [Folder] EntityClasses [Folder] FactoryClasses [Folder] .... DatabaseSpecific [Folder] ActionProcedures.cs ...

I hope you understand my structure, I can post an image if it helps.

thanks. HC

hcaldeira wrote:

Hi, thanks for fast replay.

You are right, if we use the default structure of generated projects, the classes must be public, if not, we cannot create classes from our assemblies. But as I state before, I want to encapsulate LLBLGen classes inside a layer.

To accomplish this, I had to change the templates to not generate projects *.cproj, then I included the files manually in my project, example:

DataAccessLayer.csproj [My project manually created] DatabaseGeneric [Folder] EntityClasses [Folder] FactoryClasses [Folder] .... DatabaseSpecific [Folder] ActionProcedures.cs ...

I hope you understand my structure, I can post an image if it helps.

thanks. HC

Ok, though this mitigates the factor that the databasespecific code is factored out in its own project to make possible what you want: work with the entities and not being able to do any data-access actions as that requires the database specific code.

I think you can do this though using the following: separate the databasespecific project in a different project. This is required. In dataaccesslayer, program against IDataAccessAdapter, this is an interface implemented on DataAccessAdapter. You binary reference the databasespecific project in dataaccesslayer. In dataaccesslayer you create a small internal factory where you do: internal IDataAccessAdapter CreateDataAccessAdapter() { return new DataAccessAdapter(); }

referencing the dataaccesslayer then won't offer the public DataAccessAdapter as well. Am I correct?

Hi again,

Its a good pratice to add referencies to all required assemblies in the exe project (easy publishing, etc). Then we can't prevent someone to use it directly from button1_click in some Form/UserControl inside exe project.

The best way IMO is to generate the data adapters once, then manually rename the classes and change it to internal, suppose the scenario where we want to access SQLServer and mySQL: - Generate both DatabaseSpecific (but disable task to create *.csproj, etc) and then rename the classes to not conflict - Manually include the folders DatabaseSpecificMySql and DatabaseSpecificSqlServer in our DataAccessLayer - Generate DatabaseGeneric (again disable task to create *.csproj, etc) and then search/replace the classes to change it to internal. - In runtime instantate the correct data adapter given a parameter or config.

Of course, would be nice to have this feature built-in.

HC