Tag Info

Hot answers tagged

15

For many compilers, including gcc, the -I option specifies a directory to search for include files, not an individual file. I don't know of an option to include a single file. For one thing, such an object would not specify where in the source to place the #include directive. Even if there were such an option, I would not recommend using it. The choice ...


14

No, it's not common, but yes, it should be common. Having the correct organization of a large project is way more important than any single method in itself. If your project is organized well, it is comparatively easy to understand part of it. If a small change is necessary in one isolated part, it becomes easy to find the class or method concerned, to ...


11

Since this could be a long ongoing project, I want to get the structure right from the beginning It's pretty tricky to know up front what the correct structure for a collection of code should be, especially where the project is essentially an R&D effort (for which read: you haven't personally built such a system before1). So don't bother; instead, ...


10

For my smaller applications, my BLL usually starts out as a pass-through to the DAL. I'm okay with that. As I "discover" business rules, the BLL is where I put them. I also end up finding a lot things needed in the BLL as I write my tests. For my own personal apps, I make up the business rules, and the BLL is still where I put them. For me, the BLL is ...


10

There is no industry standard as such. You could look into sample Apple Source Projects to see how they do it.. You could however, try organizing your files into Groups & associate each group to a folder.. Organize all Controllers in One Group with Subgroup for each usecase. Put all views in One Group and subgroup for each usecase. Organize All ...


9

First, it depends on what application you are doing. you should do a textual or schematic description on how a user will work with application. Fix down every possible scenario. Put down examples that will be used later for tests. Decide what belongs to the functionality and what - to the changeable configuration. Extract functionalities and data entities ...


9

Bitbucket. They provide an excellent service, private repositories in their free package (plus unlimited public) and are pretty responsive in their issue tracker. The same, minus the free private repositories, are true for Github, but I immensely dislike git. That's a personal preference, I'm not advocating against git, if for some weird reason you prefer ...


8

I would vote for the second one. In the first structure, event handlers for FeatureA are completely unrelated to event handlers for FeatureB. It seems that developers will be working on one feature at a time, and if you're working on a FeatureX request, it's far more likely that you'll need to tweak a FeatureX request handler than, say, a FeatureZ request. ...


8

It looks like you've fallen into some of the common pitfalls, but don't worry, they can be fixed :) First you need to look at your application a little differently and start breaking it down into chunks. We can split the chunks in two directions. First we can separate controlling logic (The business rules, data access code, user rights code,all that sort of ...


8

What you see there is a classic rookie mistake, establishing an is-a relationship (creating a subclass) between two classes when the actual relationship is has-a (instantiating a class as a member). It's unfortunate that this mistake made it into print. If the as-stated purpose of Main holds true, its purpose is to be a central module for an application. ...


7

I would discourage this practice, and encourage a single unified version control (and larger configuration management) policy on a per-project basis. Any individual, at any point in time, should be easily able to recreate the project as it was in a particular moment of time, and splitting the project up into multiple version control systems makes this much ...


7

One product, one source code, different data. There are not really enough details to know whether my answer is the right one, but your problem is a common one for solution providers with multiple customers who have slightly different requirements. The answers always some to converge on: Just One Product. When you build, you build everything and when you ...


6

So I would use the Adapter pattern here. Abstract the services to an interface that satisfies the needs of your app. And implement the details of that abstraction over the service. I would say this is a useful approach even if you're using one service because it helps avoid leaking the details of the underlying service into your application. For example, if ...


6

I'd like to see a library which is elegant and simple to use with Haskell. The rest is technical details that should serve this purpose, not redefine it. Thus my $0.02. Don't base it on an existing toolkit, like Qt or GTK or FLTK or... — this will severely limit you and will probably give you far more pain than profit. PyQt is, erm, funny and contrived ...


6

I'm going to take a quick first cut at this (great Q BTW!): Would imposing a structure on the large project (i.e. into smaller sub-projects) slow the compiler down? Not by enough that it matters, the overhead is actually in Maven invocations. Also, I have a slight concern on what impact this might have editing time in IDEs (we principally use ...


6

At jClarity we've definitely followed this approach. We have a 'pure' HTML5 front end - AngularJS, HTML, CSS and a host of Javascript micro frameworks which is a separate project to the backend - vert.x with a variety of verticles coded in separate JVM languages as appropriate. The trick is to have a well defined messaging API between the two that is tested ...


5

Generally, I tend to mirror the source tree for my unit tests. So, if I had src/lib/fubar, I would have a test/lib/fubar which would contains the unit tests for fubar. However, what you seem to be describing are more functional tests. In that case, I would have a multi-dimensional table that enumerated all your possible conditions. Then, the ones that ...


5

The BLL would handle things that are a part of the business domain, not a part of the database, and not a part of the UI (usually). For example, using the age of a customer to determine if they qualify for a special senior's discount. The DAL shouldn't be doing this, it should simply be retrieving the customer data, and then storing it with the discount data ...


5

Your process: Parse a word document to extract a list of contacts. Get a list of contacts in a specified group from my Google account. Compare the contacts from the word document to the Google contacts and either: Update the contacts on Google with the details from the word document or Create a new contact on Google if one doesn't exist or Delete any ...


5

Andrew, Business logic layers is what you end up with when you do domain driven development and focus on the core activities of the domain. If you strip out presentation layer (gui, web) and the infrastucture layer (db, network connectivity etc) you've got the core acitivies that are part of your domain, such as depositing money to a bank account. Now if ...


5

MVVM is a UI pattern and is used in a client. The parts of the domain in DDD that are used in the client are probably (a part of) the Model The View and ViewModel are client only. I put Repositories in (or near) the Model because they synchronize the Model to the back-end. Yes, many times this will result in multiple Person classes in different ...


5

The naming pattern also depends on your other projects. Depending on the contents of your implementation projects it could be something like this: X.DataAccessLayer X.DataAccessLayer.Sql X.DataAccessLayer.Oracle PS: I would drop 'Layer' as well, unless you have a mix of independent libraries and actual layers.


5

Prefixing (well, affixing) is really the only option. Some patterns you'll see are <library>_<name> (e.g., OpenGL, ObjC runtime), <module/class>_<name> (e.g. parts of Linux), <library>_<module/class>_<name> (e.g., GTK+). Your scheme is perfectly reasonable. Long names aren't necessarily bad if they are predictable. ...


5

Where exactly did you find these folders? Details of such a structure often depend on the project, programming language and web framework in use. This one looks like a rather typical MVC structure (model, view, controller) as often used in web projects. Though missing the view part (unless this is /src). In any case this has nothing to do with the Linux FSH ...


4

Complementing Desolate Planet's answer about Domain Driven Design: Check out also The Onion Architecture, which is very aligned with the Domain Driven Design concepts. Notice how the Business Logic "Layer" is the core of the onion and every infrastructure layer (such as the data access layer) are its external dependencies. This helps testing a lot, ...


4

Yes it make easy to develop if you categories thing on base their work.You are in right direction.In android,if develop an application then i will use following structure, something will similar like you 1)Main package With all Screen Activity 2)Adapter classes if i am using ListView, GridView that need BaseAdapter etc 3)Parsing helper if used 4)Database ...


4

First of all, there isn't really much of a comparison. The current architecture obviously grew as bits where added, and your approach is a re-design, the obvious advantage being you know exactly what the layers are and how individual components interact. It's obviously the better approach, you are introducing a middle service layer that essentially makes the ...


4

There's nothing that says you HAVE to have a certain number of tiers or layers. It all depends on the complexity of your project. Take a look at many of the MVC sample apps, like nerd dinner or record store.. they all use 2 layers because for applications that have very little processing logic, it just doesn't make sense. However, even if your app is ...


4

Maintaining external sources doesn't really add that much value. If you use particular version of library, it should be enough if you have said binary in your repository. However, if you'll make any changes to library (without making it go live/public - say you needed to add something specific to your company) then it makes sense to have modified sources as ...


4

Forget about FTP. Setup a bare repository on the server Add it as remote to your development environment. Clone the bare repo to the webspace, adapt the configuration files. Add a post-commit hook on the bare repo, starting a shell script on the webspace that pulls from the bare repo. With that, you just push your changes to remote, and it is ...



Only top voted, non community-wiki answers of a minimum length are eligible