At the risk of sounding stupid, why don't you do it two phases: 1. Read the file into a datatable, adding an additional column to represent a line number 2. Sort the table by line number (desc) and loop through. Edward
Edward Steward edwardsteward@optusnet.com.au
Cool. The best thing I like about a M:M relationship (link table) is that is easy to replicate that model out to other entities. i.e. Songs & Albums, Artists and genres, etc. One of the things that I quite enjoy is the fact that I can use a single link table for multiple relationships. This is because we use a GUID as a primary key due to our replication needs.
Edward Steward edwardsteward@optusnet.com.au
Why don't you look at providing a Many:Many relationship between the songs and artists. Ok, sure this is best performed back in the data, but you can then easily place a "LINK" class between the Songs and Artists. That way you don't have a true circular reference but you will reap the benefits. Songs (1) ---> (M) SongArtistLink (M) <--- (1) Artists I'm using this approach in our own in-house solution on a number of various entities. In the songs class, add a Readonly Artists property which references the "LINK" class. In the artists class, add a Readonly Songs property which references the "LINK" class. We've seen no perceived or measurable performance penalties using this approach and because the link is done in "data" you can then query the data at any time using any of the available tools. Hope this helps.
Edward Steward edwardsteward@optusnet.com.au
Colin, > Common UI Point taken > "DC". Data Controller/Connector Data components > DAL Noted. > Circular references My thoughts on this is to try and loosely reference varying projects/assemblies as required by using [Assembly].Load instead of "hard" referencing the projects at design time. > UI as roof Yes the UI for the pillars would consist of a series of forms that are specific to the type of pillar - debtors, creditors, etc. Edward
Edward Steward edwardsteward@optusnet.com.au
Colin, > I presume you mean n-tier where n >= 3 Yes this is true. > "logical functional units" is a very overloaded term. No two people seem to use it the same way. What do you mean by that? By "logical functional units" I refer to debtors, creditors, stock, general ledger, system, etc. > Will you really have only one UI to allow the user to interface with the enterprise application No this will be accessible from a variety of platforms > Don't force them into starting one UI for half their task and then switch to another UI in order for them to complete it No intention of it. As you can probably see from the above points you have raised my thoughts aren't altogether clear on the topic, so I think it best to elaborate on some of the finer points of the "current design". · Main application (EXE). Minimal code and almost a "stub" making reference to various UI assemblies. · A common UI assembly to be used as a control library as well as base forms · A common interface assembly handling some of the typical/common CRUD operations · A common BO assembly for common validation code, error checking, "business base" objects, etc. · A dedicated DAL assembly which all DC assemblies can hook to. The chosen DAL model I have used previously on a smaller project with much success. This has plenty of support for ALL sql db operations. · A business rules assembly to be used for custom attributes. Again have used something very similar before with much success. · Debtors - DC, I, BO, UI · Creditors - DC, I, BO, UI · Stock - etc, etc. I hope this paints a clearer picture for you and I do appreciate your input. Thanks
Edward Steward edwardsteward@optusnet.com.au
Hi to everybody, I've been asked to assist with designs for a large enterprise scale accounting project. So far I have decided upon a n-tier design with remotable objects and webservices at the server end. I'd like to gauge the responses from everybody as to when you believe the middle and even UI layers should be split up into their own assemblies. I am aware of the performance penalties associated with reflection vs. native object calls, but am also firmly believe that a large scale application will sooner or later use reflection in some way, shape or form. Based on this, my initial thoughts are to split the application into logical functional units. So following these lines of thought (and these are rough thoughts), an assembly for business objects (BO), interfaces (I), data components (DC) and user interface (UI). Each of the BO, I, DC and UI will then be replicated for each logical unit: ie. debtors, creditors, stock, general ledger, system, etc. I'd love to hear your thoughts on this and any suggestions and/or recommendations you've got. Thanks in advance.
Edward Steward edwardsteward@optusnet.com.au