2 Blazor Questions

[fundez]

I have 2 quick Blazor questions. I'm using 5.1, I haven't updated yet, but will shortly.

I'm coming from CSLA 2 and windows. I read the CSLA Blazor book and I'm trying to understand a lot of changes at once.

I used some CSLA v4 code generation templates to create some simple CSLA objects and have them working.

Does 5.2 support criteria objects? When I pass a criteriabase object it gets passed to dataportal fetch but loses all its values. If I pass an integer it comes through correctly. In both cases, I change the fetchasync and data portal fetch to accept the appropriate datatypes. Here's the call I'm using vm2.Model= await Csla.DataPortal.FetchAsync<_FUNDEZ.Business.COHeader>((new _FUNDEZ.Business.COHeaderCriteria {Identification = 10}));

Is separating the DataAccess layer from the business logic, required or recommended?

Thanks,

Mike

[rockfordlhotka]

CSLA now allows multiple parameters to data portal calls, so formal criteria types are generally not necessary. Nothing stops you from using them however.

You can still use any of the 4 data access techniques described in the Using CSLA: Data Access book. Personally I use encapsulated invocation, which is the model where methods in the business class invoke an external data access layer (DAL).

The encapsulated invocation model is, I think, particularly compelling with the new dependency injection capabilities in CSLA and .NET Core, because it really simplifies the code compared to the past.

You can look at my current working branch for ProjectTracker to see how this looks in the business classes and DAL types. (note that this branch won't be here forever - when I merge the branch into master you can look at the code in master)

[rockfordlhotka]

That said - if you know for a fact that you'll never need to switch to a different database and are willing to forgo the ability to do unit testing of the DAL, you can use encapsulated implementation, which is by far the simplest and lowest-code way to implement data access.

[fundez]

Thank You! Really helpful advice.

Mike

[fundez]

One last question can. I'm supporting a legacy database and will be using Microsft Sql for the foreseeable future and I'm not doing any unit testing. I'm planning to use encapsulated implementation. Do I have to declare Dal interface classes for use with blazor if the fetch occurs within the business object? The blazor book mentioned they were used for persistence in the client. I'm trying to simplify things as much as possible. Maintaining the interface requires a little more work.

Thanks,

Mike

[rockfordlhotka]

If you use encapsulated implementation then you don't have a separate DAL at all, and typically no DTO types or interfaces or anything.

In modern CSLA you'll inject the database connection directly into the data portal operation methods. For example:

  [Fetch]
  private void Fetch(int id, [Inject] SqlConnection conn)
  {
  }

[rockfordlhotka]

If it were me though, I'd strongly consider using Dapper instead of raw ADO.NET. It is a very thin productivity wrapper over ADO.NET that tends to make life nicer (imo).

Still, if you are comfortable with raw ADO.NET there's absolutely nothing wrong with that either!

[fundez]

Thanks @rockfordlhotka. I'll definitely checkout dapper.

Mike