I have recently taken on a project which deals with upgrading an existing flight management system to .NET and SQL Server. I have also immersed myself a bit deeper into the realms of patterns, layers, tiers, UML and the likes and at the moment I am struggling to make up my mind on how to pass data through the layers.
This project deals with basic CRUD of all flight related data with some business logic and validation and a lot of reporting. I have created an adapter project and use partial classes and possibly manager classes to deal with business logic and validation.
The data will be displayed and manipulated in some form of data grid but I am not sure on how to best pass information to and from the UI. There seems to be a lot of reluctance to pass LLBL entities into the presentation layer to satisfy low coupling of BL and PL. Of course the UI would have to know about the entities but unless I want to use the same UI on a different DAL this does not seem to matter much. Also whoever creates or modifies the UI would have to know about the created entities and how to work with them. In most cases this would be myself but even if someone else was to do some work on the UI surely it is not difficult to grasp the concept of entities and entity collections without understanding the underlying LLBL mechanism.
By the way I am not talking about the UI having access to the entities functionality only to use the entities as a flexible container to transfer a section of related data. For me this has a great advantage in terms of maintainability. If for example there is a requirement to capture a new flight property within the application all I have to do is to add it to the database and re-generate the LLBL code. I would not have to change the UI on bit as a new column with this new information is created automatically.
If I wanted to completely separate the UI from the LLBL entities I would have to create another layer to convert the entities into some form of standard data set which is then passed to the UI. Any change in the database would mean a change in this layer and more work.
The question then is: Is there a good reason not to transfer and use entities in the UI?
Any comments are most welcome!
